Entities

• In nevisMeta, clients and resource servers are represented as entities.
• Entities are created or edited using the respective icons in the main screen, see the chapter nevisMeta Web Console.

Optional metadata

Optional parameters for OAuth (to be configured as metadata, see the chapter Metadata):

• client_uri: URL of the home page of the client that the authorization server should show in the consent screen
• client_name: Descriptive name of the client that the authorization server should show in the consent screen
• client_logo: URL of an image that represents the client and that the authorization server should show in the consent screen

Client

A client is an application making protected resource requests on behalf of the resource owner (i.e., the end-user) and with its authorization. An example client might be a mobile app that wants to connect to a social media account of the user.

The term "client" doesn't imply any implementation characteristics, i.e., it may run on a server, a desktop or a mobile client.

Entity Name

The name of the client. Note: The unique technical ID of the client is defined in Client Identifier.

Role

Client.

Client Identifier

The identifier used to identify the client in requests to the authorization server (see the OAuth 2.0 Authorization Framework, chapter "Client Identifier").By default, the client identifier is automatically generated by nevisMeta as a unique and random string. Alternatively, it can also be specified by users.

Client Secret

The secret used to authenticate the client in requests to the authorization server (see the OAuth 2.0 Authorization Framework, chapter "Client Authentication").By default, the client secret is automatically generated by nevisMeta as a cryptographically strong and random string. Alternatively, it can also be specified by users.

Client URL

(Optional) URL of the home page of the client. The authorization server may show the URL to the user in the consent screen (see the OpenID Connect Core 1.0, chapter "Client Metadata").

Redirect URLs

The redirection endpoints that the client provides (see the OAuth 2.0 Authorization Framework, chapter "Redirection Endpoint"). The values must be formatted as absolute URIs

Registered Scopes

A subset of access token scopes provided by the resource server that the client intends to use (see the OAuth 2.0 Authorization Framework, chapter "Access Token Scope").When the name of a scope is entered, the text field shows matching scope names and the corresponding resource server from which the required scope can be selected.

Policies

A set of policies that instruct the authorization server on how to handle the client request, see the chapter "Policies".

For each policy it has to be defined if it is set or not set by the client

• Policy is set by the client
• Policy is not set by the client
• The default value for a policy as defined in the setup (see the chapter "Setup", section "Default Client Policies") is colored green

Response Types

The client informs the authorization server of the desired flow using the response type parameter (see the OAuth 2.0 Authorization Framework, chapter "Response Types"):CODE: Required to request an authorization code (authorization code flow)TOKEN: Required to request an access token (implicit flow)ID_TOKEN: Required to request an OpenID Connect ID token (see the OpenID Connect Core 1.0, chapter "Authentication").

PKCE Mode

Whether the client requires the use of PKCE in the authorization flow. The following types of PKCE modes are supported:

• "allowed" (default): If the client sends PKCE information in the form of a code challenge in the authorization request, the code challenge is validated. If the code challenge is not valid, the authorization fails. But if no code challenge is included in the authorization request, the authorization does not fail.
• "required": The client must send valid PKCE information. If no code challenge is included in the authorization request, the authorization fails.
• "s256-required": The client must send valid PKCE information using the S256 code challenge method. The authorization fails if no code challenge is included in the authorization request, or if the code challenge does not use the S256 code challenge method.

If the client supports the s256 code challenge method, then "s256-required" is the recommended value.

For more information, see PKCE.

Type

OAuth defines two client types based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials) (see the OAuth 2.0 Authorization Framework, chapter "Client Types"]:

PUBLIC: Applies to clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner such as an installed native application or a web browser-based application), AND incapable of secure client authentication via any other means.

CONFIDENTIAL: Applies to clients capable of maintaining the confidentiality of their credentials (e.g., clients implemented on a secure server with restricted access to the client credentials), OR capable of secure client authentication using other means.

Contacts

(Optional) One or more e-mail addresses of persons responsible for this client (separate multiple values by comma). The authorization server may show the contacts to the user in the consent screen (see the OpenID Connect Core 1.0, chapter "Client Metadata").

TTL

Default values for the time-to-live duration of tokens and consents (see the chapter "Time to live (TTL)").

Validity Date

See the chapter Validity date.

Import

When importing client entities, nevisMeta follows the given rules:

• If the newly imported client's client identifier is not unique, the application generates a new unique identifier and also re-generates the client secret attribute.
• The client secret re-newal can also be enforced for the import process by setting the module.oauthv2.import.regenerate.clientsecret configuration parameter to true as detailed in paragraph nevismeta config.

Resource server

A resource server is hosting the protected resources the client wants to access. It is capable of accepting and responding to protected resource requests using access tokens.

An example for a resource server is a social media platform such as Facebook or Twitter.

Scopes

Defines the policies (see the chapter "Policies") that are provided by the resource server per scope.

Policy configuration:

• Scope is allowed to be requested, user consent is required each time
• Scope is allowed to be requested, user consent is required once and persisted in the session
• Scope is allowed to be requested, no user consent is required
• Scope is not allowed to be requested

The default value for each policy as defined in the setup (see chapter 2.2, chapter "Default Scope Policies") is colored green Force Re-authentication Policy:

• Policy is set by default
• Policy is not set by default