Best Practices from Oracle Development's A‑Team

Oracle Identity Cloud Service: Long Lived OAuth Tokens

One of the responsibilities of Oracle Identity Cloud Service (IDCS) is to serve as an OAuth 2.0 Authorization Server. As an Authorization Server, IDCS issues access and refresh tokens to OAuth Clients. OAuth Clients use these tokens to access various resources on Resource Servers on-behalf of Resource Owners. OAuth Clients are things like web or mobile applications and Resource Owners are users who use those applications for various purposes.

This goal of this article is to clarify how IDCS sets expiration times for access and refresh tokens with different scopes. It also provides a very high-level outline of a solution design for customers who may have use-cases that require long lived access tokens for IDCS’ own scopes - I describe what these are, shortly. IDCS documentation for expiration times of different tokens is here:


IDCS is not just an OAuth Authorization Server. It also exposes a set of resources like Users, Groups etc. and REST services to manage those resources. When you configure an OAuth application in IDCS, you need to tell IDCS what resources can this application access - either IDCS’ resources, some other applications' resources, or both. Those resources are called Scopes in the OAuth terms.

Privileges to access  IDCS' own resources are granted by configuring various App Roles in the “Grant the client access to Identity Cloud Service Admin APIs” section in “Client Configuration” part of an application. Here is a screen capture from IDCS Admin Console showing this:


These are various App Roles like “User Administrator”, “Identity Domain Administrator” etc. In addition, there are some self-service roles like “Me”, “Self Registration” and others. The privileges that are required to access various IDCS end-points and perform operations on them are documented here:


IDCS scopes are documented here:


Also, the App Roles that can be granted to IDCS Clients vs Users are described here:


Privileges to access scopes exposed by other applications are granted to a client by adding scopes in "Allowed Scopes" section in “Client Configuration” part of the client application as shown in the following screen capture:

If a client application requests an access/refresh token for scopes that involve any of the IDCS’ own scopes, IDCS restricts the access token lifetime to 1 hour (3600 seconds) and refresh token life time to 1 week as documented in the Token Expiry Table.

An application can also expose its own Resources with application specific custom access / refresh token expiry times. This configuration is performed in the "Resources" part of an IDCS application as shown in the screen capture below.


Note that IDCS doesn't issue a long lived access token simply by specifying a huge value in the “Access Token Expiration” field above. This is what the documentation has to say about access token lifetime:

“Access token's (AT) expiry time is MIN (regular AT expiry, remaining session lifetime), where session = User Assertion (UA grant) or SSO expiry (Authorization Code). Regular AT Expiry is coming from Resource Server if it is available there.”

What this means is:

  • If the value is more than 8 hours (= 8 * 60 * 60 seconds = 28, 800 seconds) which is the default value for IDCS session lifetime, the resulting access token will have an expiration time value that is less than (but very close to) or equal to 28,800 seconds (note the phrase "remaining session lifetime") for its expiration time. When a refresh token is used to get a new access token and refresh token pair, the access token is valid for the full 28, 800 seconds.
  • If the specified value is less than 28,800 seconds, the access token expiration time will be that value.
  • This applies only for the custom scopes exposed by an application. If the list of scopes includes IDCS specific scopes (for example – “urn:opc:idm:__myscopes__”  or “urn:opc:idm:t.user.me”) then again the access token expiration is set to the default value of 1 hour (= 3600 seconds).

Some of our customers have use-cases that require access tokens that are capable of accessing IDCS’ own scopes and are valid for longer than an hour. The following steps outline a very high-level design that could be used to implement such use-cases:

  • Create an intermediary service that exposes its own custom resources. All IDCS operations (for example, self service) that require access to IDCS' own scopes are routed through this service which acts as a gateway. Configure this service as an application in IDCS. Define its resources and scopes and configure appropriate expiry times for Access and Refresh Tokens. Grant access to IDCS scopes (App Roles like "Me") to this service.
  • The client application is granted access only to the scopes exposed by the intermediary service above. The client application doesn't need any access to IDCS resources/scopes.
  • At run time, the client application requests access/refresh tokens from IDCS with scopes belonging to the intermediary service. As these are custom scopes, IDCS will issue a long lived access token/refresh token pair which the client can then present to the intermediary service. The intermediary performs desired validations (which could be used to improve the security posture), scope translations/mappings and gets an access token with appropriate IDCS scopes and uses it to perform operations on the client's behalf.

A detailed solution design of this use-case is a topic in itself and worthy of a separate blog post.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content