Skip to main content
Version: 8.2411.x.x RR

OAuth 2.0 authorization framework

The OAuth 2.0 authorization framework enables resource owners (i.e., end-users) to delegate limited access rights on HTTP services (resource server) to third-party applications (client), e.g., granting access on a social media account to a mobile app. Access privileges are delegated by issuing an access token with a specific scope, lifetime and other access attributes.

  • An authorization server issues an access token to a client after a user has given an approval to access his data on the according resource server. The access token is afterwards used by the client to authorize requests to the according resource server. Each issued access token has a limited lifetime.
  • Refresh tokens can be issued in addition to access tokens. A refresh token has typically a longer lifetime than an access token and can be used to request a fresh access token from the authorization server. The process of requesting a new access token with the help of a refresh token is not visible to a user and can take place anytime within the TTL of a refresh token.
  • Persisted consents can be used to store already accepted consents of a user. A persisted consent has typically a longer lifetime than a refresh token and is only stored in nevisMeta. In contrast to a token, a persisted consent is not required for the authorization process itself and it is not part of the OAuth2 specification. Persisted consents are a feature to increase the usability of the access granting process. For example, a user does not need to confirm the consent screen after every login to a certain client. A persisted consent expires after a given TTL or an explicit revocation by the user.

The diagram below shows an example of the authorization code flow between the user, client, authorization server, and resource server:

OAuth authorization code flow

For further information on the OAuth 2.0 authorization framework, see the OAuth 2.0 Authorization Framework.

OAuth in Nevis​

The figure below shows an overview of the OAuth functionality in Nevis:

OAuth in Nevis

nevisMeta provides functionality to register OAuth / OpenID Connect clients and resource servers for nevisAuth. For more details about the implementation of OAuth in Nevis, see the Reference Guide nevisAuth, chapter OAuth 2.0 and OpenID Connect plug-ins.

OpenID Connect​

OpenID Connect provides information on a user's identity on top of the OAuth 2.0 protocol. Clients are thereby not only able to access HTTP services on behalf of users, but also to verify the identity of the user based on the authentication performed by an authorization server. This is done by issuing ID tokens based on the user authentication at the authorization server. ID tokens contain claims about the authentication of a user.

For further information on OpenID Connect, see the OpenID Connect Dynamic Client Registration 1.0.