12

I have a service that allows SSO via SAML2. When SAML2 is used, we delegate the entire authentication process to the Identity Provider.

We are considering adding OAuth in order to support some mobile applications. (We don't want the user to have to log in constantly.)

It's pretty obvious how it will all work together when we are using our own Username/Password authentication, since we are in control of the entire stack.

How will OAuth interact with SAML2 SSO though? For instance, what should be done to invalidate OAuth grants if the Identity Provider removes a user? What other gotchas (and hopefully standard solutions) are there?

Shurmajee
  • 7,285
  • 5
  • 27
  • 59
brendanjerwin
  • 255
  • 2
  • 7

3 Answers3

5

Bridging the SAML and OAuth 2.0 frameworks is a well understood problem. The following stack of IETF specs provides a standard solution:

  • If you look at the core OAuth 2.0 spec (RFC 6749) and its token endpoint definition - this is basically an OAuth server endpoint which returns an access token in exchange for a "grant" -- an open-ended concept of something deemed appropriate to grant the client app the issue of an access token. In the typical OAuth scenario this is an authorisation code signifying that the user has been previously authenticated and given their consent. But the grant could also be something else.

  • There is a further IETF spec called draft-ietf-oauth-assertions-16 that builds on the core RFC 6749 standard which says that the grant can also be an assertion (a signed proof of something) and defines the necessary token request parameters for that.

  • Finally, there is draft-ietf-oauth-saml2-bearer-20, which specifies how this assertion can be a SAML 2.0 Bearer Assertion.

This standard mechanism for converting a SAML assertion into an OAuth 2.0 access token is essentially all that is needed to bridge the two frameworks.

To ensure removal of users is properly reflected by the authorisation systems there are two approaches, which can be combined:

  • Make the OAuth 2.0 access tokens short lived. This will force the client to repeat the authorisation process when the token expires, and if the user no longer exists authentication will fail and no grant (SAML assertion) will be issued.
  • Provide an API for revoking issued OAuth 2.0 access tokens, see RFC 7009 for details.
Community
  • 1
Vladimir Dzhuvinov
  • 181
  • 1
  • 4
3

OAuth is an authorization frame work. from the RFC6749

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service

And SAML is an authentication framework. SAML assertions contain authentication information.Commonly SAML is used for SSO but the SAML standard also contains an Authorization decision assertion. Which may be used for carrying some authorization information.

You can get more information from the SAML documentation here.

The question does not give details about the implementation of your system but I would suggest using authorization capabilities of SAML 2.0 rather than trying to merge two entirely different standards that serve different purposes

Community
  • 1
Shurmajee
  • 7,285
  • 5
  • 27
  • 59
3

The only implementation of this combination that I know about is Salesforce. What you are looking to do is a complex setup - both protocols are not simple and there are issues in their interaction, such as the one you've mentioned.

Have a look at this document (what SF implementation looks like from outside) - https://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth

and check this draft (I personally had not dug through it, but it's specifically addressing your case https://datatracker.ietf.org/doc/html/draft-ietf-oauth-saml2-bearer-16

Community
  • 1
Vitaly Osipov
  • 863
  • 6
  • 14