Setting Up Simple OAuth in Drupal

Please refer to the following:

https://tech.ldas.jp/en/posts/e4ce978db12227/#Creating an OAuth Client

Postman

When the grant type is password

Send a POST request to /oauth/token with the following specified in Body > x-www-form-urlencoded:

The following JSON was returned:

{
    "token_type": "Bearer",
    "expires_in": 300,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJS...",
    "refresh_token": "def50200295e412f..."
}

When decoded at jwt.io, the following was revealed:

{
  "aud": "gt8UKlK...",
  "jti": "6dc1fee..",
  "iat": 1709386974,
  "nbf": 1709386974,
  "exp": 1709387274.122002,
  "sub": "2",
  "scope": [
    "authenticated",
    "cj"
  ]
}

sub corresponds to the Drupal user ID, and scope returns the values configured in Drupal.

When logging in with a different user, a different sub was assigned.

Incorrect username or password

The following was returned:

{
    "error": "invalid_grant",
    "error_description": "The user credentials were incorrect.",
    "message": "The user credentials were incorrect."
}

Specifying an incorrect scope

When specifying an incorrect scope as follows:

The following was returned:

{
    "error": "invalid_scope",
    "error_description": "The requested scope is invalid, unknown, or malformed",
    "hint": "Check the `test` scope",
    "message": "The requested scope is invalid, unknown, or malformed"
}

Using the refresh_token grant type

When using the refresh_token grant type, username and password are not required; instead, refresh_token must be specified.

The following JSON was returned:

{
    "token_type": "Bearer",
    "expires_in": 300,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJS...",
    "refresh_token": "def50200295e412f..."
}

Using the client_credentials grant type

I tried specifying client_credentials as the grant type:

A JSON containing only an access_token was returned:

{
    "token_type": "Bearer",
    "expires_in": 300,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6..."
}

Compared to the password grant type, refresh_token was not included.

Asking ChatGPT 4

Types of grant_type

The specific strings to specify for grant_type use the values defined in the OAuth 2.0 specification. Below are the main grant_type values and their purposes:

1. Authorization Code Grant
   • String: authorization_code
   • Purpose: Used in server-side web applications, where the client receives an authorization code through a redirect from the user’s browser and uses that code to obtain an access token.
2. Implicit Grant
   • String: implicit
   • Purpose: Used in browser-based applications (e.g., single-page applications), but not recommended for security reasons in OAuth 2.0 and scheduled for removal in OAuth 2.1.
3. Resource Owner Password Credentials Grant
   • String: password
   • Purpose: Used when users provide their username and password directly to a trusted application, but not recommended for security reasons.
4. Client Credentials Grant
   • String: client_credentials
   • Purpose: Used for application-level authentication, primarily for API access between applications.
5. Refresh Token Grant
   • String: refresh_token
   • Purpose: Used to obtain a new access token when a previously obtained access token has expired.

These values are specified as the grant_type parameter in requests to the OAuth token endpoint.

Differences between the password and client_credentials grant types

Password Grant

• Grant type: password
• Purpose: Used in trusted applications where users can directly provide their username and password.
• Security: Considered high risk since credentials are passed directly; generally not recommended.

Client Credentials Grant

• Grant type: client_credentials
• Purpose: Used when the application itself is authenticated using its own credentials (client ID and client secret).
• Security: Lower risk as it does not handle user credentials.

Key Differences

• Authentication target: password uses user credentials; client_credentials uses application credentials.
• Use cases: password is for trusted client applications; client_credentials is for application-to-application authentication.
• Security: password directly handles user credentials with higher risk; client_credentials is limited to application-level authentication with lower risk.

Example with Nuxt 3 frontend and Drupal backend

1. Password Grant Flow

1. User authentication: User enters credentials in the Nuxt 3 application.
2. Token request: Nuxt 3 sends credentials with grant_type=password to the Drupal OAuth endpoint.
3. Token issuance: Drupal verifies and returns an access token (and optionally a refresh token).
4. Using the access token: Nuxt 3 accesses protected resources on behalf of the user.

2. Client Credentials Grant Flow

1. Application authentication: Nuxt 3 sends its client ID and secret with grant_type=client_credentials to the Drupal OAuth endpoint.
2. Token issuance: Drupal verifies and returns an access token.
3. Using the access token: Nuxt 3 accesses protected resources for its own purposes.

Selection Criteria

• Password Grant: Suitable when users need to log in directly. Requires careful security handling.
• Client Credentials Grant: Suitable for application-to-application scenarios such as background data synchronization.

Handling Refresh Tokens

• password grant type: A refresh token is issued along with the access token, used to obtain new tokens when the current one expires.
• client_credentials grant type: A refresh token is typically not issued. The application must re-authenticate with its credentials when the access token expires.

This difference exists because password handles end-user credentials where refresh tokens help manage sessions, while client_credentials is for application-level authentication where session management is not needed.

Summary

I am gradually gaining a better understanding of the differences between OAuth grant types and the handling of refresh tokens.

There may be some inaccuracies, but I hope this serves as a useful reference.