OpenAM - Mobile Access

The common topic from customers these days is how to integrate their mobile applications with OpenAM.

I will usually use the material from Shoot Me a Token: OpenAM as an OAuth2 Provider. Victor wrote this quite some time ago when I attended the 1st Open Identity Summit in the US. But it's still relevant.


So, there are a few ways to integrate mobile applications with OpenAM - OAuth2, OpenID Connect or REST. All methods are language independent, which is good.

The most common integration will be OAuth2. With OAuth2 in mind, one has to differentiate that there are in fact 2 types of tokens - Access Token & Refresh Token. The lifetime of a refresh token is long. So, a refresh token is used to exchange for a new access token (which is short-lived). This is important concept. Otherwise, users will need to keep logging in.

A real life example would be your Facebook application on your mobile phone. Are you prompted to log in every day? I don't even recall when did I last logged in. Technically, it's the "refresh token exchanging for an access token" in play.

In order for OpenAM to behave like Facebook (ok, this is very layman), the OAuth2 Provider feature in OpenAM has to be enabled. Once enabled, OpenAM can now provide the same functionalities as Facebook. It is now able to issue access and refresh token to mobile applications. It is now OAuth2-aware.


Some customers will then want to know more about what's going on behind the scene. Well, Victor's slides have it all. I just need to highlight a bit to make it complete.


The very 1st time a user access a mobile application (OAUTH2 Demo), he will be prompted with a consent page.

OpenAM will display the same to user. Depending on which OpenAM version you are using, you might get this:

Yes, so UI customization is required. :)  Or if you might get this:

I have not tested the latest UI yet. (Currently on a OpenAM 12 project, OAuth2 is in next phase)

So, after user has given his consent (highlighted in RED), an attribute in the user's LDAP entry is updated to "remember" user has in fact given his consent. This will prevent the Consent Page to be displayed again.

Once that's done, the mobile application will request for an Access Token and this will be stored in the Key Chain on the handphone (highlighted in BLUE). At the same time, the Refresh Token is stored.

The next time the user fires up the mobile application, it will retrieve the Access Token. If it has not expired, it will be used to request token information from OpenAM.

If the Access Token is expired, then the Refresh Token will be used to exchange for a new Access Token. The new Access Token will be stored in the Key Chain.

The extreme case will be the Refresh Token has also expired. Then users will be forced to re-login again.

That explains why some sites have their Refresh Token set to be months or even year. Just long enough for you to change handphone. :)



Futher readings:

[Concept] Working with Mobile Devices & Applications

[Sample] OpenAM OAuth 2.0 iOS Sample App

* I have not tested the sample codes yet. No comment there.


.