Supporting Different URLs for Getting Refresh Token and Access Token
Remote Identity Providers can provide different types of tokens. Declarative provider supports token URL for both access and refresh tokens. Separate refresh token URLs will be added in meta data API.
After the refresh token URL is added, a new URL will be returned if it is not empty, otherwise it returns the token URL to keep the current behavior. Declarative provider uses the refreshTokenUrl
at regular IDP level if the URL is set.
A common use case is getting a seperate refresh token URL when the old one is expired. The job invokes the token refresh endpoint to obtain the access token.
Refresh tokens do expire, but are typically long-lived.
Note:
The default value for therefreshTokenExpiry
attribute is seven days.
Step 1: Get the idcs infra token
Make a GET request to the /Apps
endpoint, requesting a specific App ID, and then specify the refreshTokenExpiry
attribute.
Request Example
GET tenant-base-url/admin/v1/Apps/{{appID}}?attributes=refreshTokenExpiry
Response Example
The refreshTokenExpiry
attribute is returned in the response.
{ To be added later}
Step 2: Update Social meta data with updated refreshTokenUrl
To update the refreshTokenExpiry
attribute value, make a POST request to the /Apps
endpoint specifying the App ID, and then define the updated refreshTokenExpiry
attribute value in the payload.
Request Example
"refreshTokenPhase":
{ "url": "https://www.googleapis.com/oauth2/v4/token",
"method": "post"
}
Response Example
The response returned includes the updated refreshTokenExpiry
attribute value.
{To be added later}
Step 3: Obtain idcsjob app secret
Request Example
Get the client secret by running the following command.
$IDCS_CODE/idaas/admin-srv/build/install/admin-srv/bin/admin-srv
--boot.config /scratch/idcs/app/data/conf/boot.conf.local oauth_token getClientSecret
--tenant idcs-oracle -ci idcsjob
Step 4: Obtain access token for idcs job using the secret
Access token is obtained using the client secret obtained in Step 3
curl --noproxy '*' --insecure --silent --location --connect-timeout 7
-H "Content-Type: application/x-www-form-urlencoded"
-X POST -d "grant_type=client_credentials&client_id=idcsjob&client_secret=<some secret>&scope=urn:opc:idm:__myscopes_"host01.example.com:8943/oauth2/v1/token
Step 5: Invoke refresh token endpoint
Use access token obtained in Step 4 to invoke the refresh token endpoint.
curl --noproxy '*' --insecure --silent --location
-H "Authorization: Bearer <some access token>"
-H "Content-Type: application/x-www-form-urlencoded"
-X POST -d "idp_name=Google Provisioning&refresh_token=<refresh token>"https://tenant-base-url/oauth2/v1/social/tokenrefresh
Step 6: Update refreshTokenUrl
on the regular associated IDP
Request Example
{ "schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp" ],
"Operations": [ {
"op":"replace", "path":"refreshTokenUrl",
"value":"https://www.googleapis.com/oauth2/v4/token"
} ]}
When the refresh token url is added at the regular associated IDP, it will take precedence on the URL added at declarative provider and is used for refreshing the access token.