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/independentidThe 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).
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.
Great article Phil!
We implement OAuth service for clients and most of them are unaware that the actual authentication is outside the scope of the specification. This does open an opportunity to merge whatever authentication scheme that the customer already has in place. When this is a federated relationship, protocols like WS-Fed and SAML are great answers to avoid the need to share passwords. In fact, we have implemented the exact SAML based solution you describe above (http://www.assurebridge.com/our-products/mobileconnect/).
I do have one question. What do you mean by NASCAR style authentication?
NASCAR is where you present a screen with a bunch of clickable buttons representing different authentication methods and/or sources.
But, what do you do when the user is deprovisioned in the IdP, and still has valid oAuth tokens? The user can access the APIs until explicitly deprovisioned from the SP (using SCIM, for example). But until this is done, the user still has access. This is unlike SAML browser SSO flows, in which access is denied when the user is deprovisioned in the IdP, simply because the SAML flows go through the IdP for each login.
SAML has the same issue. The lifetime of the SSO aassertion can mean the user still has access after revication by the IDP.
OAuth addresses this by using refresh tokens. This allows access tokens with very short lifespans and forces the client to "refresh" which re-verifies the authorization and the user's right to authz is still valid.
Post a Comment