OAuth2 Password Grant vs OpenID Connect

5
votes

I've been reading about OAuth and OpenID Connect extensively, but this question is specifically about the OAuth2 Resource Owner Password Grant (aka OAuth2 Resource owner credentials Grant, aka OAuth2 Password Grant)

Some resources (like the book "OAuth2 in Action" by Justin Richer) says not to use OAuth2 Resource Owner Password Grant for authentication - see section 6.1.3 in the book.

Other good resources like the following all say we can use the OAuth2 Resource Owner Password Grant to essentially authenticate users via trusted apps:

  1. https://www.oauth.com/oauth2-servers/access-tokens/password-grant/
  2. https://stormpath.com/blog/the-ultimate-guide-to-mobile-api-security
  3. https://www.youtube.com/watch?v=FNz0Lupp8HM&index=60&list=PLyUlngzGzkztgTizxM6_zqiw8sRj7vBm0
  4. https://docs.apigee.com/api-services/content/implementing-password-grant-type
  5. https://oauth2.thephpleague.com/authorization-server/which-grant/
  6. https://aaronparecki.com/oauth-2-simplified/#others

But I'm having a hard time understanding why we shouldn't use the OAuth2 Resource Owner Password Grant as essentially proof of a successful authentication?

My understanding of Resource Owner Password Grant flow is that a username and password is provided by the end user to the trusted client (my native app), which then forwards it to my API's OAuth server and exchanges it for an access token (and optional refresh token) that it can use for the rest of the authenticated API endpoints. The native app doesn't save the username/password, but instead relies on the short-lived access token and the longer-lived refresh token (to get fresh access tokens when they expire).

Why would I even need OpenID Connect? Why can't I just use OAuth2 Resource Owner Password Grant as an authentication mechanism?

Both the native app and the API are developed by the same person (me).

Any explanations would be welcome. Thank you.

3
apisecurityauthenticationoauthopenid-connect
Did you ever find an answer to your question? Im confused about same exact thing. – Dannyboy

3 Answers

3
votes

If both the server and the client application are yours, you may use Resource Owner Password Credentials flow to get access tokens.

If the server is yours but client applications are not yours (= if client applications are developed by third-party vendors), your server should not allow client applications to use Resource Owner Password Credentials flow. It's because Resource Owner Password Credentials flow cannot prevent third-party client applications from stealing end-users' passwords.

The specification of OpenID Connect does not describe how an OpenID provider should authenticate end-users. Instead, the specification describes how an OpenID provider should generate ID tokens. Because an ID token contains a signature generated by the OpenID provider, client applications that receive the ID token can verify that the ID token has been really signed by the OpenID provider.

That is, OpenID Connect is a specification as to how to make the result of end-user authentication be verifiable. It's not a specification as to how to authenticate end-users.

1
votes

The resource owner credentials grant is of the higher risk then any other grants and defeats the purpose of the protocol, which aims to hide user credentials from the client application.

In the case of native app - you are right, its possible to analyze your app and retrieve the consumer key from it. Also I can imagine someone creates an app similar to yours, and fishes user's password out of it, and executes other potentially malicious actions without users noticing.

I suggest you read the specifications of OAuth2 and OpenID Connect. Why should you NOT use the resource owner password grant (from OAuth2 spec):

The resource owner password credentials grant type is often used for legacy or migration reasons. It reduces the overall risk of storing usernames and passwords by the client but does not eliminate the need to expose highly privileged credentials to the client.

This grant type carries a higher risk than other grant types because it maintains the password anti-pattern this protocol seeks to avoid. The client could abuse the password, or the password could unintentionally be disclosed to an attacker (e.g., via log files or other records kept by the client).

Additionally, because the resource owner does not have control over the authorization process (the resource owner's involvement ends when it hands over its credentials to the client), the client can obtain access tokens with a broader scope than desired by the resource owner. The authorization server should consider the scope and lifetime of access tokens issued via this grant type.

The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible.