Password Credentials Grant Type in OAuth 2.0

The Password Credentials Grant Type, often just called the "Resource Owner Password Credentials" (ROPC) flow, is a way for users to directly provide their username and password to obtain an access token. Current security guidance (RFC 9700) says this grant type MUST NOT be used, because the client application sees the user's password. It still exists in older systems, so you may meet it when testing one.

What You Enter in LoadFocus

In a load test, set Authorization Type to OAuth 2.0 and Grant Type to Password Credentials. The form has these fields:

• Token Name: a label for you. It is not sent to the server.
• Access Token URL: the provider's token endpoint.
• Username, Password: the account the token is requested for. Use a dedicated test account, not a personal one.
• Client ID, Client Secret, Scope, Audience: as issued by or agreed with your provider (Audience is provider-specific).

Before the test starts, LoadFocus sends one POST request to the Access Token URL over HTTPS, with these fields as a JSON body, and reads access_token from the JSON response. RFC 6749 describes a form-encoded body, so if your provider rejects the request, check whether its token endpoint accepts JSON.

How Does Password Credentials Work?

1. User Input:

• The user provides their username and password directly to the client application.

2. Requesting the Token:

• The client then sends these credentials to the authorization server's token endpoint. This request also typically includes the client's client_id and client_secret, though some implementations might not require the client secret for this flow.

3. Token Response:

• If the credentials are valid, the authorization server responds with an access token (and possibly a refresh token). The client can then use this token to make requests on behalf of the user to the resource server.

How to Configure Password Credentials?

1. Register Your Application:

• As with other OAuth 2.0 flows, begin by registering your application with the OAuth 2.0 provider. You'll usually be given a client_id and client_secret after registration.

2. Input Mechanism:

• Implement a mechanism in your client application where users can enter their username and password. This could be a simple login form.

3. Token Request:

• When users provide their credentials, your application should make a POST request to the authorization server's token endpoint. This request should include the grant_type (set to "password"), username, password, client_id, and possibly client_secret. Ensure this request is made securely using HTTPS.

4. Handle the Token Response:

• If the credentials are correct, the authorization server will respond with an access token, which your application should store securely. Optionally, you might also receive a refresh token, which can be used to obtain new access tokens when the current one expires.

5. Use the Token:

• As with other grant types, once you have an access token, you can use it to make authorized requests to the resource server on behalf of the user.

6. Token Renewal:

• If you received a refresh token and the access token expires, use the refresh token to get a new access token without asking the user for their credentials again.

Considerations:

• Security Concerns: This grant type involves sharing the actual password with the client, which is a significant security risk. It's essential to ensure that the client is entirely trustworthy.

• Do Not Use It for New Systems: RFC 9700 says this grant MUST NOT be used. If you control the system, move to the Authorization Code grant (with PKCE), or to Client Credentials for service-to-service calls.

Conclusion:

The Password Credentials Grant Type is simple, but it exposes the user's password to the client and current guidance says not to use it. Only use it in a test when the system you are testing still requires it, and keep the credentials to a dedicated test account.