- Tokens
- Access Tokens
- Refresh Tokens
- ID Tokens
- Proof-of-Possession (PoP) Tokens
-
Grant Type
- Scopes
- PKCE (RFC 7636)
-
Client Management
- Using "Client ID Alias"
- Token management policy when deleting clients
- Authlete's policy on managing clients which have been authorized by user
- Client Attributes
- Authorization Requests
- User Authentication
- Error Handling
- Client Authentication
- Introspection
- Userinfo Endpoint
- JARM
- Device Flow (RFC 8628)
Authlete's policy on managing clients which have been authorized by user
Overview
An Authlete-powered authorization server can leverage /client/authorization/get/list API to retrieve a list of clients which has been authorized by a specific user.
In order to make the list, Authlete checks its token database to see which clients' tokens are stored. Expiration time for each token doesn't matter i.e. existence of tokens is only considered.
Details
Authlete provides your authorization server with an API response including information on clients correlated with access tokens and/or refresh tokens which have been stored in Authlete's token database. The following conditions affect existence of tokens in the database.
Either one of an access token or a refresh token is valid (not expired)
The valid token is surely stored in the database. Thus Authlete provides information on the client correlated with the token.
Both an access token and a refresh token are expired
Even in such case, Authlete provides information on the client correlated with the expired tokens if they have been still stored (i.e. not been swept) in the token database. Authlete removes such expired tokens when:
- Accepting /api/auth/introspection request that contains the access token
- Executing batch removal (cleanup) process
- Accepting explicit removal request e.g. /api/client/authorization/delete API
How did we do with this article?