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 clientNote: 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](https://tools.ietf.org/html/rfc6749#section-2.2)"). 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](https://tools.ietf.org/html/rfc6749#section-2.3)"). 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](https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)").

Redirect URLs

The redirection endpoints that the client provides (see the OAuth 2.0 Authorization Framework, chapter Redirection Endpoint](https://tools.ietf.org/html/rfc6749#section-3.1.2)")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](https://tools.ietf.org/html/rfc6749#section-3.3)"). 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, 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](https://tools.ietf.org/html/rfc6749#section-3.1.1)"):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](https://openid.net/specs/openid-connect-core-1_0.html#Authentication)").

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](https://tools.ietf.org/html/rfc6749#section-2.1):PUBLICApplies 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.CONFIDENTIALApplies 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](https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)").

TTL

Default values for the time-to-live duration of tokens and consents )

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 the section 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