Table of Contents
Updating issued token(s)
Overview
Authlete provides two types of APIs for updating information (e.g. scopes, expiration time) of issued token(s). These APIs are different each other in terms of how to specify token(s) and which information can be updated.
| Updating a single token | Updating tokens related to a pair of a client and a user | |
|---|---|---|
| API | /auth/token/update | /client/authorization/update |
| How to specify token(s) | An access token (“accessToken”) | A pair of a client (“clientId”) and a user (“subject”) |
| # of tokens | 1 | At least 1 |
| Item(s) to be updated |
|
|
This article summarizes these methods.
Updating a single token
Authlete provides /auth/token/update API. You can modify values e.g. new expiration time (“accessTokenExpiresAt”), new scope (“scopes”) etc. in an arbitrary token which has been issued to the client.
In addition, you can store any key/value pairs, which are not related to OAuth 2.0, to Authlete’s database as properties (“properties”). This feature is useful when you have some information related to access token and would like to have Authlete to manage them.
Updating tokens related to both a certain client and a user
Authlete provides /client/authorization/update API. Tokens to be updated are determined with a client (“clientId”) and a user (“subject”), one of those who have granted access to the client.
This API is useful when you would like to update all of permissions which a specific user have allowed to a specific client. An example use case is as follows:
- A user grants read-only access to a client for first-time usage. The client obtains a first access token which has “read” scope.
- The user uses the client for some time and comes to consider that he/she can allow the client to update his/her information. Thus the user grants read-write access as well as read-only to the client. The client obtains another new second token which has “read” and “write.”
- The user keeps using the client and sometime changes his/her mind. The user would like to revoke the write permission. So the user logs in to authorization server, browses a list of clients connected, and revoke “write” access which has been granted to the client.
The authorization server can leverage the /client/authorization/update API to implement feature of 3 above. It can be done by just hitting this API with a new scope value (“read”), rather than doing search-and-update for each token.
For your reference, there is an example in another article (Managing issued tokens granted by each user), section “Updating authorization scopes for one of clients which have been authorized by a user”.