• A resource server is an entity that stores a protected resource.
• In Digital Access component, this is the Access Point, even though it does not actually store any resource. As a reverse proxy it can seamlessly extend any resource with OAuth 2.0 access token validation without the resource needing any knowledge of OAuth 2.0.

• A resource owner is an entity that owns a specific resource (data) and is capable of granting a client access to that resource.
• In Digital Access component this is a user. Can also be referred to as an ‘end-user’.

• A client is an application that wants to access a protected resource on behalf of a resource owner. There are two types of clients in OAuth 2.0, confidential clients and public clients.
• A confidential client is a client that can keep a secret (for example, an application executing on a secure server)
• A public client is a client that cannot keep a secret (for example, a mobile device or web app).
• In order to get access to the resource the client must first obtain a token through one of the token grant flows. A token gives access to a specific set of scopes that must be defined before registering a client.

A scope refers to a collection of one or more resources that are protected by OAuth 2.0.

An access token is issued to a client in order to allow that client to access one or more scopes on behalf of a specific resource owner.

This is the general grant flow:

1. The client redirects the resource owner to the authorization server with a request for a specific set of scopes.
2. The authorization server authenticates the client and the resource owner.
3. The resource owner consents to the client accessing the requested scopes.
4. The authorization server creates an access token and redirects the resource owner back to the client together with the token.

The authorization code grant type is the preferred way to obtain access tokens (and refresh tokens) with a confidential client. Other grant types should only be considered for public clients or when the added level of security is redundant (for example, when the client is a secure server on the same network).

These are the steps in the authorization code grant flow:

1. The client redirects the resource owner to the authorization server’s /authorize endpoint, providing client identification and the set of scopes that the client wants to get access to.
2. The authorization server identifies the client and ensures that the client is allowed to access the requested scopes.
3. The authorization server authenticates the resource owner if the user does not already have an authenticated session.
4. The authorization server presents the resource owner with the requested scopes and asks for consent.
5. The resource owner is redirected back to the client. If consent was given, an access code is included in the URL.
6. The client extracts the code from the URL and makes a request to the /token endpoint on the authorization server, providing the extracted code.
7. The authorization server authenticates the client, validates the code, and returns an access token (and refresh token) to the client.

The implicit grant type is intended for public clients. Refresh tokens are never issued when using this grant type. Specifically, this grant type is intended to be used by clients executing in the resource owner’s browser and is the only one which does not authenticate the client. This grant type should only be used if other grant types are unavailable. Impersonating a client that has this grant type enabled is as easy as knowing their client ID. The authenticity of the client is left (almost) entirely to the resource owner’s discretion.

These are the steps in the implicit grant flow:

1. The client redirects the resource owner to the authorization server’s /authorize endpoint, providing the set of scopes that the client wants to get access to.
2. The authorization server authenticates the resource owner and ensures that the client is allowed to access the requested scopes.
3. The authorization server presents the resource owner with the requested scopes and asks for consent.
4. The resource owner is redirected back to the client. If consent was given, an access token is included in the URL.

The resource owner password credentials grant type is intended for confidential clients with a high degree of trust from the resource owner. The strength of not needing to provide the client with the resource owner’s credentials is lost by using this grant type. This grant type is used to eliminate the need for the client to store the resource owner’s credentials by exchanging them for a long-lived token. It is suited for clients such as a device’s operating system which may have access to the resource owner’s credentials anyway, or is trusted to not misuse or unintentionally expose the resource owner’s credentials.

These are the steps in the resource owner password credentialsgrant flow:

1. The client obtains the resource owner’s username and password.
2. The client sends a request to the authorization server’s /token endpoint, providing the resource owner’s username and password and the set of scopes that the client wants to get access to.
3. The authorization server authenticates the client and resource owner and ensures that the client is allowed to access the requested scopes.
4. The authorization server returns an access token (and refresh token) to the client.

The client credentials grant type is intended for confidential clients that do not act on behalf of a resource owner. In other words, this grant type is used when accessing resources not owned by a user.

These are the steps in the client credentialsgrant flow:

1. The client sends a request to the authorization server’s /token endpoint, providing the set of scopes that the client wants to get access to.
2. The authorization server authenticates the client and ensures that the client is allowed to access the requested scopes.
3. The authorization server returns an access token (and refresh token) to the client.

The refresh token grant type is a special grant type. When refresh tokens are enabled on the OAuth 2.0 client, other grant types (with the exception of implicit) will issue a refresh token alongside the access token. The refresh token has a longer lifetime than the access token and can be used to receive a new access token without needing to authenticate the resource owner. Since the refresh token is only sent to the client once and then isn’t exposed again until it is consumed, using refresh tokens is safer than using long-lived access tokens. Digital Access component will only issue refresh tokens to clients that are configured to have refresh tokens issued.

These are the steps in the refresh tokengrant flow:

1. The client sends a request to the authorization server’s /token endpoint, providing the refresh token.
2. The authorization server authenticates the client, validates the refresh token, and ensures that the client is (still) allowed to access the requested scopes.
3. The authorization server returns an access token (and refresh token) to the client.