Mobile App Development with OAuth 2.0 and IDCS: A High Level Approach


IDCS is used by enterprises and organizations to allow secure access to their applications.  IDCS uses various open standards such as OAuth 2.0, SAML etc. to protect these applications.  One of the many features of IDCS is to facilitate client applications accessing backend (REST) APIs using OAuth 2.0 (  Client applications come in different flavors – traditional web applications hosted on a web server to JavaScript running on a browser.  However, recently mobile apps have become very popular.  The good news is that IDCS supports all variants of client applications including mobile.

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.

OAuth 2.0 for Mobile Apps

The specification “OAuth 2.0 for Native Apps” ( 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:

  • mobile apps should be defined as public client as they are incapable of protecting any credentials
  • mobile apps should use the authorization code grant flow
  • PKCE ( should be used to protect the authorization code from being hijacked 
  • a browser independent of the app (in-app browser tab pattern) needs to be used during the flow

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 –

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).

Fig 1.0 OAuth 2.0 for Mobile Apps

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 ( ) 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.

User Authentication, IDCS and IDPs

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 –

Fig 2.0 IDCS federating with other identity sources


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)-

Fig 3.0 IDCS federating with ADFS

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.

IDCS Configuration for Mobile Apps

The following A-Team post – – 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 –

  • mobile apps are configured as public clients
  • only the authorization code grant flow is allowed
  • PKCE should be used to protect the authorization token
  • A system browser or in-app browser using the mobile platform’s capabilities (such as iOS’s SFSafariViewController) should be used for user authentication

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.



Add Your Comment