OAuth: Does it replace federation?

Today I received a question about OAuth and whether it replaces existing federation deployments. Would OAuth, WS-Trust, and SAML work together? The answer is no. In fact, OAuth is built to use any authentication system, local or federated.

Note: Coincidentally, Paul Madsen, also posted an interesting graphic that gives a swim lane view of OAuth's flow with an IDP. 

I discussed some of this in my earlier post "OAuth: Does it authenticate?" Instead of prescribing what authentication is possible with OAuth, the OAuth specification simply assumes that there is some form of authentication mechanism in place that is acceptable to the service provider. It could be local authentication (e.g. as seen on Facebook, etc), or federation from SAML, OpenID, etc.

Here are a couple of diagrams (click to enlarge) showing the use of OAuth with a federated IDP. In Figure 1, the client application "ClientApp" of an employee of "IndependentId Enterprise" wants to access a cloud application service hosted by cloudsvc.org. In step 1, ClientApp sends an authorize request to the cloud service via the smartphone browser to the endpoint:

https://cloudsvc.org/authorize/cloudService/independentid

The authorization service determines if the browser already has an authenticated Web SSO session with the user. If not, the authorization point determines the user's home IDP by looking at the original authorize URL. In this case, it indicates the authorization was for IndependentId.com. The user's browser is redirected to IndependentId's SAML IDP where the user authenticates and a SAML Assertion is returned (step 2).

Figure 1

In Figure 2, the Cloud Service Provider having received the users SAML Assertion and authenticating the user, determines by policy that all IndependentId users automatically grant access to the "CloudApp Service". In step 3, the authorization service then redirects the users browser back to:

clientApp://independentid&code=i1WsRn1uB1&

The phone switches to ClientApp and passes it the redirect URL which contains the authorization code. In step 4, ClientApp then uses the code, along with its own client_id and client credentials (e.g. client_secret) and obtains an access token. Finally, in step 5, the client app is able to access the CloudApp Service. Note that the ClientApp can continue accessing the service for as long as the access token is valid which may be minutes, hours, days, or permenantly depending on the security requirements.

Figure 2

There are lots more variations on this. For example, during the authorization request, the IDP endpoint may not be known. In that case a NASCAR style authentication process could take place. Also, in step 4, the token server could elect to return a refresh token. This allows the ClientApp to maintain a longer session with the service without having to re-authenticate the user. Meanwhile, access tokens still maintain a shorter lifetime forcing the ClientApp to silently re-authenticate and provide a refresh token to continue to validate the clients access over time.