Authorization server
The following data elements are stored or accessible on the authorization server:
- usernames and passwords
- client ids and secrets
- client-specific refresh tokens
- client-specific access tokens
- HTTPS certificate/key
- per-authorization process: "redirect_uri", "client_id", authorization "code"
Resource server
The following data elements are stored or accessible on the resource server:
- user data (out of scope)
- HTTPS certificate/key
- either authorization server credentials or authorization server shared secret/public key
- access tokens (per request)
It is assumed that a resource server has no knowledge of refresh tokens, user passwords, or client secrets.
Client
The following data elements are stored or accessible on the client:
- client id (and client secret or corresponding client credential)
one or more refresh tokens (persistent) and access tokens
(transient) per end user or other security-context or delegation
context- trusted certification authority (CA) certificates (HTTPS)
- per-authorization process: "redirect_uri", authorization "code"
bearer token
A ’bearer token’ is a token that can be used by any client who has received the token (e.g., [RFC6750]). Because mere possession is enough to use the token, it is important that communication between endpoints be secured to ensure that only authorized endpoints may capture the token. The bearer token is convenient for client applications, as it does not require them to do anything to use them (such as a proof of identity). Bearer tokens have similar characteristics to web single-sign-on (SSO)
cookies used in browsers.
proof token
A ’proof token’ is a token that can only be used by a specific client. Each use of the token requires the client to perform some action that proves that it is the authorized user of the token. Examples of this are MAC-type access tokens, which require the client to digitally sign the resource request with a secret corresponding to the particular token sent with the request.