OAuth and SAML: Mobile meets enterprise

OAuth has become the de-facto standard for mobile application authentication.  SAML is the single sign-on mechanism of choice for enterprise web applications.  Why would you need both?  Imagine this common scenario.  You are deploying a cool new mobile application on a Mobile App Server in the cloud.

Some of your customers may log into it directly with new user ids and passwords.  But your corporate customers want to use their existing company credentials.

Mobile-CorporateUserChallenge

Further, the corporate security department is unwilling to share the company passwords with your mobile application.  Just to make matters more complex, users won’t use your mobile application if they have to retype in their username and password every time they use the application.

This is a terrific opportunity for merging SAML and OAuth.  If we recall from the previous blog, OAuth is all about exchanging user credentials for an access token.  The access token is used to grant permission for the mobile application to talk to (and get data from) the mobile app server.  The token is usually good for a certain length of time (days/weeks/months) and then expires and must be renewed.  But, OAuth does not specify exactly how the user actually presents the user credentials.  On simple mobile apps, the app simply displays a popup screen asking for a user id and password and sends it on up to the mobile server.  This is one way to do it but it does not have to work this way.  The authentication can be done with the classic SAML based exchange and effectively allowing the user to exchange a SAML assertion for and OAuth access token.  This has the following advantages:

  • The mobile app does not receive the user’s password
  • The user’s passwords are not stored outside of the corporate network
  • The mobile app contact the server without re-entering the password until the token expires or is revoked

Here’s how it works:

Mobile-CorporateUserSolution

 

  1. The mobile app attempts to retrieve a OAuth access token from the OAuth server (first time or expired).   Realizing it needs new Authentication, the mobile app opens a browser.
  2. The OAuth/SAML server create a SAML Authentication Request and redirects the browser back to the Enterprise SSO server.
  3. The Enterprise SSO server logs the user in (if not already logged in), creates a SAML assertion and redirects the mobile browser back to the OAuth/SAML Server.
  4. The OAuth/SAML server verifies the SAML Assertion and issues an OAuth token to the mobile app.
  5. The mobile app uses the token to access the application on the mobile app server.
  6. The mobile app server verifies the token with the OAuth server.

Using a mobile device’s browser ensures that the password is never passed through the mobile app.  The OAuth server can set policy to expire the token after a preset amount of time as well as revoke tokens if the user leaves the company.

From the user’s point of view, the login is quick and seamless.  The browser based popup can be tailored to look like it is part of the mobile app so the user sees a consistent experience.  They are unaware of the SAML handshake and just see the login as a simple userid/password request screen.

This is the approach that we use at AssureBridge with our MobileConnect™ service.  We find it bridges the need for corporations to protect their credentials with the ease of access demanded by mobile users.