Overview

We verify OAuth authentication using Drupal’s Simple OAuth and Postman.

I previously wrote the following article, but this time I will explore it further.

Configure Simple OAuth in Drupal

Please refer to the following.

/en/posts/e4ce978db12227/#oauthクライアントの作成

Postman

When the grant type is password

For /oauth/token, the following was specified in Body > x-www-form-urlencoded:

KeyValue
grant_typepassword
client_id{created CLIENT_ID, e.g., gt8UKlKltI4qs1XP5KLucIXiYw9ulGb0xS4RyO437dc}
client_secret{created CLIENT_SECRET, e.g., test}
username{username, e.g., yamato}
password{password, e.g., yamato}

As a result, the following JSON was returned:

{}""""tearoxcekpcfeiernrse_essts_hy_t_piotenko""ek::ne"n"3:"B0:e0"a,e"rydeJer0f"e5,X0A2i0O0i2J9K5Ve14Q1i2LfC.J.h.b"GciOiJS...",

When checked with jwt.io, it was decoded as follows:

{}"""""""]ajinessutabxuc""ditfpboac""""""puj::::::et""h""111":eg67772ntd000"[t8c999,iU1333cKf888ale667tKe992e..777d..444".",,.,",1,22002,

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

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

Entering incorrect username or password

The following was returned:

{}"""eemrrerrsoosrra"_g:dee""s:icnr"viTaphlteiidou_nsg"er:ran"ctTr"he,edeunsteiralcsrewdeernetiianlcsorwreercet.i"ncorrect.",

Specifying an incorrect scope

Specifying an incorrect scope as follows:

KeyValue
grant_typepassword
client_id{created CLIENT_ID, e.g., gt8UKlKltI4qs1XP5KLucIXiYw9ulGb0xS4RyO437dc}
client_secret{created CLIENT_SECRET, e.g., test}
username{username, e.g., yamato}
password{password, e.g., yamato}
scopetest

The following was returned:

{}""""eehmrrierrnsootsrr"a"_:g:dee"""sC:ichnre"vicTapkhlteiitdohr_nees"qc:`uotep"eseTst"hte,e`drsseccqoouppeees"t,iesdisncvoapleidi,suinnkvnaolwind,,ournkmnaolwfno,rmoerd"malformed",

Using grant type refresh_token

When using grant type refresh_token, username and password are not required, and refresh_token needs to be specified.

KeyValue
grant_typerefresh_token
client_id{created CLIENT_ID, e.g., gt8UKlKltI4qs1XP5KLucIXiYw9ulGb0xS4RyO437dc}
client_secret{created CLIENT_SECRET, e.g., test}
refresh_tokendef50200a7d875010a068813927613be306944301b05358dd2dff39758cba3faa94ab2e6603c6a2e5a58d0262967f19fc6936ea764057f018df087c42fb5bcc0166db225efa7ce351dd6c82b64765350d6297e80e1118e9da7e004d2e17294d2b213b9d9c08ff16b29e6a59ffade5584e9aba4d2bda91b57cb7538c62b79520f…

As a result, the following JSON was returned:

{}""""tearoxcekpcfeiernrse_essts_hy_t_piotenko""ek::ne"n"3:"B0:e0"a,e"rydeJer0f"e5,X0A2i0O0i2J9K5Ve14Q1i2LfC.J.h.b"GciOiJS...",

Using grant type client_credentials

The grant type client_credentials was specified as follows:

KeyValue
grant_typeclient_credentials
client_id{created CLIENT_ID, e.g., gt8UKlKltI4qs1XP5KLucIXiYw9ulGb0xS4RyO437dc}
client_secret{created CLIENT_SECRET, e.g., test}
username{username, e.g., yamato}
password{password, e.g., yamato}

As a result, JSON containing only the access_token was returned:

{}"""teaoxckpceienrs_ests_y_tpioenk""e::n""3:B0e0"a,eryeJr0"e,XAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjIxZjYxOThlMWIxNTI0ZGM1NTcxZjJiZDM3N2M4NWI2N2IzYTE1NDU5MWVjZTUwN2QzNDEwNjBkYmVhNDEyOTg5MjI5NDAzYjFkOTFlODBmIn0.eyJhdWQiOiJndDhVS2xLbHR..."

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 values defined in the OAuth 2.0 specification. Below are the main grant_type values and their uses:

  1. Authorization Code Grant

    • String: authorization_code
    • Use: Used in server-side web applications where the client receives an authorization code from the user’s browser through a redirect and uses that code to obtain an access token.

  2. Implicit Grant

    • String: implicit
    • Use: Used in browser-based applications (e.g., single-page applications), but not recommended in OAuth 2.0 for security reasons and is planned for removal in OAuth 2.1.

  3. Resource Owner Password Credentials Grant

    • String: password
    • Use: 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
    • Use: Used for application self-authentication, primarily for API access between applications.

  5. Refresh Token Grant

    • String: refresh_token
    • Use: 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. By selecting the appropriate grant_type, applications can securely communicate with the OAuth server and implement the necessary authentication flow.

Difference Between password and client_credentials Grant Types

The password grant type and client_credentials grant type represent different authentication flows defined in OAuth 2.0, each corresponding to different use cases and security requirements. Here, the differences between each are explained.

Password Grant

  • Grant Type: password
  • Use: This flow is used in trusted applications where users can directly provide their username and password to the client application. This method allows user authentication credentials to be passed to the application only when the user trusts the application.
  • Security: Since username and password are passed directly to the application, it is considered a high security risk and is generally not recommended. Special care must be taken in handling user credentials.

Client Credentials Grant

  • Grant Type: client_credentials
  • Use: This flow is used when the application itself is authenticated. Instead of accessing on behalf of a user, the application uses its own credentials (client ID and client secret) for authentication to gain access to APIs and resources.
  • Security: This flow is limited to authentication between applications and does not handle user credentials, so the security risk is considered lower compared to the password grant type. The application maintains its own credentials and uses them for authentication.

Key Differences

  • Authentication target: password uses user credentials, while client_credentials uses application credentials.
  • Use cases: password is limited to specific trusted client applications, while client_credentials is suitable for authentication between applications.
  • Security: password handles user credentials directly, raising security concerns, while client_credentials is limited to application self-authentication, resulting in lower risk.

The selection of the appropriate grant type should be based on the application’s use case, security requirements, and the trust relationship with users.

What about a frontend application built with Nuxt 3 and a backend/OAuth client built with Drupal?

Using a frontend application built with Nuxt 3 and a backend/OAuth client built with Drupal as an example, the authentication flows using the password grant type and client_credentials grant type are explained.

1. Password Grant Flow

In this scenario, the user directly provides authentication credentials (username and password) to the Nuxt 3 frontend application. The frontend application then uses this information to obtain a token from the Drupal backend.

  1. User authentication: The user enters login information (username and password) in the Nuxt 3 application.
  2. Token request: The Nuxt 3 application sends the authentication credentials received from the user as a POST request with grant_type=password to the Drupal backend’s OAuth endpoint.
  3. Token issuance: The Drupal backend validates the user’s credentials and, upon successful authentication, returns an access token (and optionally a refresh token) to the Nuxt 3 application.
  4. Using the access token: The Nuxt 3 application uses this access token to access protected resources on the Drupal backend on behalf of the user.

2. Client Credentials Grant Flow

In this scenario, the Nuxt 3 application itself is authenticated against the Drupal backend and requests access to resources for the application itself rather than a user.

  1. Application authentication: The Nuxt 3 application sends a POST request with grant_type=client_credentials using its own client ID and client secret to the Drupal backend’s OAuth endpoint.
  2. Token issuance: The Drupal backend validates the application’s credentials and, upon successful authentication, returns an access token to the Nuxt 3 application.
  3. Using the access token: The Nuxt 3 application uses this access token to access protected resources on the Drupal backend for the application itself.

Selection Criteria

  • Password Grant is suitable when users need to log in directly to the frontend application. However, since it handles user credentials directly, security considerations are needed.
  • Client Credentials Grant is suitable for scenarios where the application uses APIs for its own purposes, such as synchronizing data in the background. It is an authentication flow without user involvement.

Handling of Refresh Tokens

For the password grant type

  1. User authentication: The user enters username and password in the Nuxt 3 app’s login form.
  2. Token request: The Drupal backend requests a token from the OAuth server using the authentication credentials received from the user and the password grant type.
  3. Token response: The OAuth server validates the request and, if the credentials are correct, returns an access token and refresh token to Drupal.
  4. Access & Refresh: The Drupal backend uses the access token to access protected resources and uses the refresh token to obtain new tokens when the access token expires.

For the client_credentials grant type

  1. Application authentication: The Drupal backend makes a token request with the client_credentials grant type using its own client ID and client secret to the OAuth server.
  2. Token response: The OAuth server validates the request and, if the credentials are correct, returns only an access token to Drupal. In this case, no refresh token is returned.
  3. Application-to-application access: The Drupal backend uses the obtained access token to access other protected resources and APIs.

Handling of Refresh Tokens

  • password grant type: Based on user authentication, a refresh token is issued along with the access token. The refresh token is used to obtain a new access token when the original access token expires.
  • client_credentials grant type: Based on application self-authentication, a refresh token is typically not issued. When the access token expires, the application must request a new access token using its client credentials again.

This difference exists because the password grant type handles end-user credentials, making refresh tokens useful for user session management, while the client_credentials grant type is used in scenarios where the application authenticates itself and session management is unnecessary.

Summary

I gradually came to understand the differences between grant types used in OAuth and the differences in handling of refresh_token that accompany them.

There may be some errors, but we hope this serves as a useful reference.