The Doorkeeper configuration enables the Resource Owner Password Grant, as shown in the code snippet below (config/initializers/doorkeeper.rb).
grant_flows %w[authorization_code implicit_oidc password]
The password grant is configured properly: the method resource_owner_from_credentials is implemented and correctly validates username and password (single-factor authentication), properly setting the user information for the current request if the credentials match.
Hence a OIDC application may obtain an access token from the user's credentials:
POST /oauth/token HTTP/1.1
Host: eyedp.example.com
Connection: close
Content-Type: application/json
Content-Length: 203
{
"username":"admin",
"password": "Password4!",
"grant_type": "password",
"client_id":"Qzo7EdDO1Jcw5UCdbOdI5TJhOYb4JmEsJ7cqFWRqX3I",
"client_secret":"Mcqw4qDarfeXdXB2S7PZPfO9SOF_J_5CTdNEXG7Wl88"
}
The request is successful, and the response contains the access token:
HTTP/1.1 200 OK
Server: nginx/1.21.5
Date: Wed, 26 Jan 2022 11:19:30 GMT
{
"access_token":"gyJCv-WZqBr4DrbXgLztjSYBNSyNALS7AS0NtsOiG9U",
"token_type":"Bearer",
"expires_in":7200,
"created_at":1643195970
}
The use of the password grant is discouraged by the OAuth 2.0 specification, especially when applications are not first-party (i.e., SSO applications), as this method of obtaining an access token bypasses the second factor authentication and may expose credentials to the service provider. Quoting the OAuth 2.0 specifications (RFC 6749), §1.3.3, the credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).
Impact
Having the password grant flow enabled by default is not considered a secure default, as it may allow SSO applications to request password-based credentials to the users rather than using the SSO flow.
Patches
This issue is resolved in commit e39c25c. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory:
The Doorkeeper configuration enables the Resource Owner Password Grant, as shown in the code snippet below (
config/initializers/doorkeeper.rb).The password grant is configured properly: the method resource_owner_from_credentials is implemented and correctly validates username and password (single-factor authentication), properly setting the user information for the current request if the credentials match.
Hence a OIDC application may obtain an access token from the user's credentials:
The request is successful, and the response contains the access token:
The use of the password grant is discouraged by the OAuth 2.0 specification, especially when applications are not first-party (i.e., SSO applications), as this method of obtaining an access token bypasses the second factor authentication and may expose credentials to the service provider. Quoting the OAuth 2.0 specifications (RFC 6749), §1.3.3, the credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).
Impact
Having the password grant flow enabled by default is not considered a secure default, as it may allow SSO applications to request password-based credentials to the users rather than using the SSO flow.
Patches
This issue is resolved in commit e39c25c. Users should upgrade to the latest commit on main or to a 1.0.0 or later release.
Workarounds
None
For more information
If you have any questions or comments about this advisory: