IBM Security Access Manager provides a set of capabilities that can be used for authentication and authorization of a client accessing API’s and can be scoped to a user or clients needs.
When you moving away from browser use cases, REST based API’s depend less on session cookies and instead make use of security tokens. The client can often persist data between sessions, and ability to drive authentication dynamically requires client programming.
OAuth is a preferred choice for mobile or thick clients because the username and password don’t need to be stored, but rather a set of tokens that can be remotely revoked. They can also be overlaid with additional security constraints such as a PIN as a second factor or an electronic device fingerprint to more tightly bind the tokens to the issued device.
There is now an SDK Available to expedite your development on the mobile application side:
IBM Security Mobile Access SDK
OAuth 2.0 defines 4 major flows:
- Resource Owner Password Credential (ROPC)
This is used when you have a trusted client, such as a mobile application you designed and developed. The user is generally asked to provide their existing credentials into the application and the application is “trusted” to handle them securely, and securely discard them once the authentication flow has been completed.The generated OAuth tokens are then stored securely on the device – in the secure enclave provided by the operating system (ie iOS KeyChain or Android KeyStore). When accessing an API – the OAuth Access Token is provided in the request as a HTTP header.
- Authorization Code Flow
This is generally* used when the user is accessing servers via a web browser. In this scenario, the OAuth “Client” is a 3rd party server, and not the users browser.This flow is useful when you need to passed scoped access to a users resources to another server. One use case where this can be useful might be a bank or retirement fund/superannuation company offering API access to a users balance to a financial reporting company. Rather than a user having to share their Internet banking credentials to the 3rd party service, they delegate access to a read only balance API via OAuth.In this flow, the user doesn’t enter their ISAM credentials into anything except the ISAM protected domain.
- Implicit Grant
This is a less common flow, but is intended for use where the client is JavaScript or similar running in a users browser. Its most typically used when the client is interacting via API’s that aren’t already authenticated by the existing session or cookie domain.The flow is very similar to the authorization code flow, except that the client is actually code running in the browser. No refresh token is issued, client authentication isn’t necessary (as it provides no additional value) and consent isn’t required.When using this flow with ISAM – it’s important that the API protected endpoint is a seperate ISAM web domain, and that either no ISAM cookie is sent with the request or that the ISAM cookie name is different between the web based access instance and the api protection instance. - Client Credentials
This flow is similar to Basic Authentication flow, and used when there is no “user” in the picture. For example, when the third party server shown in the Authorization Code Flow needed to update some metadata or share information that isn’t related to a user.The OAuth client sends its client ID and client secret, requesting a client credential, and is issued a access token representing the server. No refresh token is issued, the server simply repeats the exchange when the token expires.
[*] I say generally here – because there are some neat ways the Authorization Code flow can be used in other scenarios, but this isn’t the place to go into it in more detail.
When using ISAM with OAuth authentication, you can then make use of ISAM’s junction single sign on capabilities. This means that an OAuth token can be used by the client, but any of the standard mechanisms ISAM supports including HTTP header (iv-user), Forms SSO, Kerberos, Basic Auth, LTPA and TFIM Junctions.
Philip Nye 