Is using a SSO Assertion (JWT or SAML) For OAuth Assertion Flow Common?

1
votes

I'm working on a set of systems that are exposing REST APIs that are authenticated using OAuth 2. Various of these systems have their own indpendant sets of user accounts, there is no common notion of a user identifier across all the systems.

For interactive usage we already have a SAML Single Sign On solution, so the users can sign on once to the identity provider (which knows their user accounts in all systems) and then be automatically signed in to each system using SAML.

I'd like to extend this pattern to our OAuth 2 authenticated APIs. I.e. allow the users to authenticate once with their Identity Provider credentials, then be able to trigger the OAuth 2 authentication flow against each system to obtain a bearer token, without the need for the user to enter each set of credentials.

I've found 2 draft specs that would allow me to achieve this:

But these are both draft, and before investing too heavily I'd like to understand if these patterns are in relatively wide usage or if I'm backing an edge case technology.

So my questions are:

  • Are these kinds of SSO pattern common with OAuth 2?
  • Are there alternatives in common use for solving the same problem?

It appears that these drafts were authored by Salesforce.com and are in use by them: SAML, JWT.

I've also seen a few questions here around their use for Salesforce.com which would suggest they're actually used at least.

I also see an unanswered question asking if Windows Azure supports this flow which would suggest that other people are at least looking for the same problem.

It appears that google uses the JWT variant for server to server applications using a "service account" Details Here

2
oauthoauth-2.0single-sign-onsamljwt
Have you looked into OpenID Connect? – Robby Cornelissen
@RobbyCornelissen I've looked at Open ID connect, as I understand it it's solving a subtly different problem (though perhaps I'm missreading). Open ID connect seems to target common authentication between systems that share a single user identity, just like Open ID did. I'm looking more for a SSO across security domains where an Identity Provider is able to assert an independent user identity in a different security domain. – EdC

2 Answers

1
votes

We use the Salesforce endpoints extensively for token exchange and do exactly what you are trying to do. Other systems have conceptually similar, but slightly different implementations, returning different forms of access_token (e.g. SAP, AWS are 2 good examples).

All these are following a model in which they are the issuers of the security artifacts used to call their API. In other words:

  1. A user authenticates (to a website).
  2. There's something that represents that authentication (e.g a SAML token)
  3. You call a specific API to exchange the user artifact for an API access_token.

A different approach used by other apps is to do for APIs the same thing they do for a website: use an artifact that can be generated from a trusted entity in a standard way. JWTs are a good candidate for that. The latter is used by Azure Mobile Services, Firebase, Layer.com.

In our implementation, we chose the latter model by default, but also implemented an abstraction for all systems in the former, and simplify user code. We call this an "identity delegation" endpoint, and it's signature looks like this. The api_type parameter defines what sort of system you are exchanging the token for (SAP, Salesforce, Layer, etc.).

1
votes

Let me start with an observation for the problem you describe. Essentially the observation is that federation across multiple OAuth Authorization Servers hasn't really been solved as a commodity. In other words, each set of protected resources has its own OAS that you need to request a token. I have run into this problem and business requirement.

I am going under the assumption that the IdP that issued the identity assertion (e.g. SAML, WS-Federation) is not the same as the resource server hosting the OAuth secured API. One technique I have used is to go back to the server that issued the identity and leverage an STS to exchange the identity for a SAML Bearer token and provide the SAML Bearer to the OAuth Authorization Server (OAS) that has been integrated to the resource you are trying to access, which then issues an Access Token for its secure APIs. Of course, this only works if the IdP that issued the initial assertion also provides a STS to get the SAML Bearer token. The JWT profile you have documented above is where the thought leaders within industry are working to solve the federation problem across multiple OAuth Authorization Servers. I haven't seen it integrated much across industry yet.