This blog enumerates the steps required to incorporate OAuth 2.0 in mobile apps where IDCS serves as the authorization server. OAuth 2.0 is a comprehensive security framework; this blog focusses specifically on fetching and using the two tokens - authorization grant and access. It does not get into the nitty-gritty details of exact SDK calls, various HTTP requests and responses, rather provides a high level conceptual approach which can serve as a guidance to a mobile app developer.
The specification "OAuth 2.0 for Native Apps" (https://tools.ietf.org/html/rfc8252) profiles the use case for a native application acting as a client. Since mobile apps belong to this category, they should comply with this specification. Broadly speaking, the specification mandates the following:
There are other important security aspects which are required and recommended by the RFC, but this blog will focus on just the above four points. The last point about app independent browser needs further elaboration. It is possible for a mobile app to display the login page of the authorization server (IDCS) in multiple ways -
a) "web-view", browser embedded inside the app. Examples include UIWebView on iOS, Android's WebView, etc. This is deemed unsafe - https://tools.ietf.org/html/rfc8252#section-8.12.
b) system browser (e.g. Safari) launched externally. This is acceptable from security standpoint, however, not as efficient as the next alternative.
c) browser launched within the app using mobile platform constructs such as iOS's SFSafariViewController or Android Custom Tab. This is the most efficient method, addressing user experience, customizations and security concerns.
The following sequence diagram illustrates the interaction between various stakeholders while executing the OAuth 2.0 flow. In this use case, a mobile app is accessing the PaaS service Oracle Autonomous Mobile Cloud Enterprise (AMCe).
The above flow can be segmented into 4 phases:
i) Step 1 - Mobile platforms enable an app to spawn off a system or a native browser - SFSafariViewController in iOS is an example.
ii) Steps 2-5 - in this phase the user is authenticated while providing authorization to the client. Since the user's interaction with IDCS is happening in the context of the system browser, the app does not and cannot learn about the user's credentials, one of the central tenets of the RFC.
iii) Step 6 - Mobile platform hands over the response from IDCS to the app. Although the redirect URI was sent as a HTTP 302 redirect response, the mobile platform does not conduct any redirects, instead hands over the response to the app. Various options are defined in the specification (https://tools.ietf.org/html/rfc8252#section-7 ) which enable a mobile platform to handle such redirects.
iv) Steps 7-10 - rest of the flow.
Since the mobile app is a public client type, PKCE is used to protect the authorization code as in steps 2 and 7 in the diagram above. One of the key takeaways from the above diagram is the 2nd phase - steps 2-5. Note how the mobile app is out of the loop during this phase: the interactions are just between the system browser (user) and IDCS. This phase involves user authentication and authorization (scope selection by user). The mobile app should not be concerned how the user is getting authenticated or providing authorization. Hence mobile app developers need to focus on just three phases handling steps 1, 6 and 7-10.
In the previous section, the user gets authenticated after submitting the credentials. Who does the authentication? In Fig 1.0 above, IDCS is doing the authentication locally. Although IDCS can do that, that need not be the case. Today's enterprises allow a range of IDP choices, both on-premise such as OAM, ADFS, and cloud based social identity providers such Google, Facebook, etc. The landscape looks like the following -
Here IDCS forwards user authentication requests to the external IDPs with which it federates. In such scenarios, the sequence diagram of Fig 1.0 turns into the following (ADFS as the IDP)-
Similar to Fig 1.0 where IDCS was acting as the local IDP, in this case too the mobile app is out of the picture during the user authentication process which now involves the external IDP ADFS.
The following A-Team post - http://www.ateam-oracle.com/identity-cloud-service-mobile-clients-and-pkce-support/ - covers IDCS configuration for mobile apps. It also discusses how PKCE is used to protect the authorization grant flow.
This article looked from a very high level how mobile apps can incorporate OAuth 2.0 for secure access to APIs. Developers need to be cognizant about the following 4 aspects -
A consequence of using the system browser is that the mobile app is delinked with the actual authentication process. Hence the developer does not have to consider which authentication protocol - SAML, OpenID Connect, etc. - is used while developing the mobile application. That's a freebee provided by OAuth 2.0.