...

Synapse expects that the provided <access_token>, is a Synapse issued JSON Web Token (JWT). Synapse currently supports two types of JWT access_tokens that are both designed for two different use cases:

• 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 order for a user to acquire either type of access token, they must first authenticate their identity. Once authenticated, one of these two bearer access tokens will be issued (depending on the context). It is important to emphasis emphasize that both of these access token types are bearer tokens. Since authentication was required to acquire them, they can be presented The bearer presents the access token as proof of authentication. In other words, Synapse will accept the bearer of such access tokens authenticated, with , so no further authentication is required.

Stolen Access Tokens

Since access tokens are bearer tokens, if a 3rd party were to steal another user’s access token, the 3rd party could use it to impersonate the token’s owner. For example, an access token can be acquired by a malicious party using a phishing scheme. It is also possible that the owner of an access token might accidentally make it available to others. Consider the cases where a user puts an access token directly into a script to run a quick test. If they forget about the access token, and later create a pull request that includes the script, they will unwitting unwittingly share the access token with the world. In fact, this is such a common problem, that GitHub offers a “push protection” feature to help organizations deal with it.

...

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:

...

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.

OIDCAccessTokenRequest.json

{
	"description": "Request for a single page of outstanding OIDCAccessTokenInfo for the given userId",
	"properties": {
		"userId": {
			"type": "string",
			"description": "The ID of the user that owns the access tokens"
		},
		"nextPageToken": {
			"type": "string",
			"description": "Optional. Forward the 'nextPageToken' from a previous response to get the next page."
		}
	}
}

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

...

...

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.