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 URIs (separate multiple values by comma or semi colon). Valid URI format: http/https-uri-scheme private-use-uri-scheme URI must not contain whitespaces or fragments.

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.

Id Token signature algorithm

(Optional) Algorithm used to sign the Id Token, see the OpenID Connect Core 1.0, chapter Client Metadata. Default value is RS256. Supported values are: RS256, RS384, RS512, ES256, ES256K, ES384, ES512.

Id Token encryption algorithm

(Optional) Algorithm for encrypting the Id Token. This field signals that the ID Token should be encrypted. If the property is not set, no encryption will be done. The public key for the encryption is taken from the JWKS URI or JWKS fields. The key is picked by algorithm family and type. In case more than one key is found, the one having the longest validity is used. Note, that keys having no validity defined are valid indefinitely. For more information, see the OpenID Connect Core 1.0, chapter Client Metadata. Supported values are: RSA1_5, RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384, RSA-OAEP-512, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW.

Id Token encryption method

(Optional) Encryption method for the ID Token. This property only makes sense if Id Token encryption algorithm is also set, setting this property without the Id Token encryption algorithm will result in an error. Supported values are: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512, A128GCM, A192GCM, A256GCM. For more see the OpenID Connect Core 1.0, chapter Client Metadata.

JWKS

(Optional) Public key in JWKS format. The JWKS and JWKS URI must not be used together, see the OpenID Connect Core 1.0, chapter Client Metadata

JWKS URI

(Optional) URL of the JWKS endpoint of the client. The JWKS and JWKS URI must not be used together, see the OpenID Connect Core 1.0, chapter Client Metadata.

Logo URI

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

ToS URI

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

Policy URI

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

Token Endpoint Auth Method

The client informs the authorization server how to do authentication for the token endpoint:

• NONE: No authentication method required. This can only be set, when the client Type is public and no secret is set.
• CLIENT_SECRET_BASIC: Basic authentication method required for accessing the token endpoint.
• CLIENT_SECRET_POST: Basic authentication method required for accessing the token endpoint in a POST request.
• CLIENT_SECRET_JWT: Authentication method required for accessing the token endpoint using a JSON Web Token.

Pushed Authorization Request Required

The client informs the authorization server force to use Pushed Authorization Request:

• false: Authorization server can accept Pushed Authorization Request beside original request.
• true: Authorization Server forced to use Pushed Authorization Request.

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. The default value for a policy is defined in the setup, seeDefault Client Policies.

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)")

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](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 OpenID Connect Core 1.0, chapter Client Metadata.

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

Custom claims mapping:

• Allow mapping between custom scope and custom claim(s).
• Default scopes of OAuth 2.0/OpenID Connect cannot set custom claim(s).
• In single scope, the claim name must be unique.