Search code examples
oauth-2.0single-sign-onopenid-connectauth0

Authorization Code flow vs. resource owner password grant for trusted applications

I'm having an issue trying to resolve this in my head... Authorization code flow seems to be for 3rd party applications, which is why is makes the user grant permission to the application at the Authorization server.

When the user logs in, the Authorization Server opens a session so that the user doesn't need to login again if they are using another 3rd party application, they may however need to grant that application permissions, but not provide a username / password due to the session cookie with the Authorization Server.

However, with Trusted applications provided by the Identity Provider, they usually use Resource Owner Password Grant, as they don't want to require the user give permissions to the application.

This brings forth a problem, because they are no longer using Authorization Code flow, they can no longer take advantage of the session cookie the user has with the authorization server... so how can SSO be done between these 2 different types of flows?

If there was a way to specify trusted applications in AuthCode, this would no longer be a problem, but that is not provided by the spec, nor seems to be in any OAuth2 / OpenID connect software that I am aware of.

The second would be to implement some non-standard backend communication with the IDP to get the session information...

I'd love to know if anyone has solved this issue in other creative ways.

Solution

  • As you suggest, a disadvantage of the Resource Owner Password Credentials (ROPC) grant type is that you have to provide username/password credentials to the Client which in principle prevents the Client from taking part in an SSO system.

    You could come up with a creative way to obtain an SSO token/session and pass that in to the Client to validate via the ROPC flow in the "password" field against the Authorization Server but you'd be re-inventing the Authorization Code grant type yourself in a non-standard way.

    In short: avoid using the Resource Owner Password Credentials grant type if you can. It is a deprecated grant type in OAuth 2.0 only meant to be used in migration scenarios.