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:
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:
A detailed solution design of this use-case is a topic in itself and worthy of a separate blog post.