...
Personal Access Token - Permanent / Long Term token used by long running processes and services.
OpenID Connect Session Access Token (AKA OIDC Access Tokens) Access Token - Temporary / Short Term tokens used for interactive client sessions.
...
In a recent, penetration test, the pen tester successful acquired an OIDC Access Token from a Synapse user via a phishing scheme. With no means to revoke the stolen token, its owner was unable to prevent the stolen OIDC access token from being used. In addition, “logging out” did not revoke the OIDC Access Token. for more information see:
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
Session Access Token API Changes
With the current OIDC Session Access Token implementation, we do not need to store any information about the tokens in the database. Instead, we can validate each token by checking its cryptographic signature. However, this optimization means we have no mechanism to revoke OIDC Session Access Tokens.
To address this issue we propose adding tracking information for each OIDC Session Access Token issued to our database. This will allow us to support APIs for both listing and revoking outstanding OIDC Session access tokens.
Response | URL | Request | Description | Authorization | OIDCAccessTokenResponse | GET /user/{userId}/OIDCAccessToken | OIDCAccessTokenRequest | Get a paginated list of outstanding OIDC AccessTokens issued to the identified user. | Provided access token must belong to the {uesrId} or to an Admin.|
|---|---|---|---|---|---|---|---|---|---|
DELETE /user/{userId}/OIDCAccessTokenSessionAccessToken/all | Revoke all outstanding OIDC access tokens associated with the {userId}. | Provided access token must belong to the {uesrIduserId} or to an Admin. | |||||||
DELETE /OIDCAccessTokenSessionAccessToken | Revoke the OIDC access token used to make this call. This can be used to “log out”. | Not for Admin use. | DELETE /user/{userId}/OIDCAccessToken/{tokenId} | Revoke a specific OIDC access token identified by {tokenId} that belongs to {userID}. | Provided access token must belong to the {uesrId} or to an Admin. |
OIDCAccessTokenRequest.json
...
| language | json |
|---|
...
. |
...
OIDCAccessTokenResponse.json
...
...
{
"description": "A single page of OIDCAccessTokenInfo with a nextPageToken to get more results.",
"properties": {
"page": {
"type": "array",
"description": "A single page of access tokens",
"items": {
"$ref": "org.sagebionetworks.repo.OIDCAccessTokenInfo"
}
},
"nextPageToken": {
"type": "string",
"description": "Token that can be used to get the next page. Null if there are no more results."
}
}
}OIDCAccessTokenInfo.json
| Code Block | ||
|---|---|---|
| ||
{
"description": "Information about an outstanding OIDC access token",
"properties": {
"tokenId": {
"type": "string",
"description": "The unique ID of the OIDC access token"
},
"expiresOn": {
"type": "string",
"format": "date-time",
"description": "The data-time when this access token expires."
},
"userId": {
"type": "string",
"description": "The ID of the user that owns this access token"
}
}
} |
Open Questions
Should we attempt to capture additional information such as IP address and client when issuing OIDC Access Tokens? Per our discussion: No. At this time we will not list outstanding tokens, as we only have two use case: revoke the current token or revoke all tokens.
Should we restrict the use of OIDC Access Tokens to same IP address that it was issued? Per our discussion, this could cause usability problems and unexpected behavior. It is something we can explore again in the future.
When a OIDC Access Token is used, should we track additional information like IP address and client? Since we will no longer list outstanding token, this does not seem necessary.