...

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 (OIDC) 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 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

...

{
	"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?

• Should we restrict the use of OIDC Access Tokens to same IP address that it was issued?

• When a OIDC Access Token is used, should we track additional information like IP address and client?