Using OAM OAuth interfaces to secure mobile apps

Introduction

When using OAuth interfaces in OAM Mobile Services, there are two high level options to secure native mobile apps. This simple post is hopefully useful to our new customers and describes a sample flow for each of those options as well as the token types involved irrespective of using the SDK or using native REST interfaces directly from within the app. In subsequent posts I'll describe these interfaces in more detail.

Use 2-legged OAuth flow

1. User opens the mobile application
2. Application sends application information and device profile to OAMMS. This happens automatically behind the scenes. OAMMS performs application registration and creates a unique client assertion for the user
3. User inputs username (login) and password.
4. If user authentication is successful then the user is issued a JWT User Assertion otherwise the user is displayed an error message
5. User then obtains a JWT Access Token and accesses a REST API resource within the application
6. If the user wants to now access an OAM protected resource -

• The application code performs a token exchange and first obtains an OAM Master Token from the JWT User Assertion
• The application code then obtains a OAM Access Token from the OAM Master Token by passing in the application resource context

In this case, you can use OAuth REST APIs within the Android or iOS application. In PS3 we will have an SDK to support this flow. However with the PS3 SDK you cannot do step 6 in this flow. In PS3 when using REST APIs directly you will also be able to strong authentication for this user using KBA after step 3.

Use 3-legged OAuth flow

1. User opens the mobile application
2. Application sends application information and device profile to OAMMS. This happens automatically behind the scenes. OAMMS performs application registration and creates a unique client assertion for the user
3. User inputs  username (login) and password.
4. If the user authentication fails here, then an error is thrown/error page is displayed
5. If OAM-OAAM integration is configured via the TAP scheme, the user is prompted for strong authentication via KBA
6. If the strong authentication fails, then an error is thrown/error page is displayed
7. User is then asked to provide explicit consent on a consent page—to verify that the client application is  allowed access to the REST API. The consent page is OAM protected
8. The consent page can be displayed in the embedded browser or in the external browser
1. If the consent page is displayed in the embedded browser, the mobile app also obtains an OAM_ID cookie that it can use to access OAM protected resources—as the OAM_ID cookie is stored/issued within the context of the mobile app.
2. If the consent page is displayed in the external browser, the mobile app does not obtain an OAM_ID cookie that it can use to access OAM protected resources –as the OAM_ID cookie is stored/issued outside the context of the mobile app.
9. If user authentication is successful and the user has provided consent then the user is issued a JWT User Assertion otherwise the user is displayed an error message.
10. User then obtains a JWT Access Token and accesses a REST API resource within the application.

• If step 8.1 was followed the user can seamlessly access an OAM protected resource within the app as well
• If step 8.2 was followed and the user wants to access an OAM protected resource -The application code performs a token exchange and first obtains an OAM Master Token from the JWT User Assertion
• The application code then obtains a OAM Access Token from the OAM Master Token by passing in the application resource context
• The user accesses the OAM protected resource from the mobile application

In this case again, you can use OAuth REST APIs within the Android or iOS application. Also in PS3 we will have an SDK to support this flow.

Token Types in OAM Mobile Services

• OAM MT – user session token representing authenticated OAM session. It can be set as OAM_ID cookie
• OAM AT - represents access token authorizing access to scoped OAM webgate protected resource. It is basically the OAM AuthnCookie.
• OAM UT – OAM AT scoped for OAMMS server
• JWT Client Assertion – represents the client application
• JWT AT – represents access token authorizing access to scoped REST resource
• JWT User Assertion :  JWT AT with global scope

Also note that in a 3 legged flow, the mobile app automatically leverages OAM password policies such forgot/change/reset password, account lockout functionality through native OAM password policy functionality (or via OAM-OIM integration) since user (resource owner) authentication is performed while accessing an OAM protected consent page while in the case of a 2 legged flow, the resource owner username/password are sent in a basic authorization header directly to the LDAP server (bypassing OAM in step 3,4 in the 2-legged flow) and hence only native LDAP password policies apply.

Finally, if you want to implement token exchange where you want to reissue an expired OAM token based on a longer duration JWT UT, then you will again to need to use REST interfaces directly as there is no PS3 SDK support for this. We support PIN based authentication for this as documented here -http://docs.oracle.com/cd/E40329_01/dev.1112/e27134/restapioauthl.htm#CHDCECJH