Skip to main content

Reference

In this section, you'll find a detailed explanation of the available options for setting up an OAuth 2.0 Provider.

Core​

  • Display metadata: This flag enables OAuth 2.0 provide metadata disclosure as stated in the OAuth 2.0 Authorization Server Metadata (RFC8414).

  • Allow self-registration of a client: This flag enables client self registration as stated in the OAuth 2.0 Dynamic Client Registration Protocol (RFC7591).

  • Provider name: This is the provider's required name. It will be displayed in the list of providers and used when referencing the provider in other Monokee configurations. The name has not a default value and must be inserted.

  • Issuer: This is the issuer that will be use in all OAuth 2.0 tokens. Issuer is a unique identifier for a OAuth 2.0 Provider. The default issuer is composed as follows: https://<(new.monokee.com/<domain_id>|<domain-custom-fqdn>)>/oauth2/<provider_id> it's editing is possible but discouraged.

  • Grant types supported: This is the list of the grant types supported by the OAuth 2.0 Provider. Available values are authorization_code, implicit, client_credentials, password, refresh_token and urn:ietf:params:oauth:grant-type:device_code. Gran types password and implicit are discouraged.

  • Token endpoint authentication methods supported: This is the list of supported authentication mechanism to access the token endpoint. The token endpoint is the endpoint used to issue access token in the authorization_code, client_credentials, password, refresh_token and urn:ietf:params:oauth:grant-type:device_code grants. To access this endpoint the OAuth 2.0 client should be authenticated, different mechanisms are available:

    • none: this setting disable the authentication.
    • client_secret_post: this setting allows client_id and client_secret to be sent in POST body using application/x-www-form-urlencoded format.
    • client_secret_basic: this setting allows client_id and client_secret to be sent in Authorization header in basic auth format: Basic <Based64(client_id:client_secret)>.
    • client_secret_jwt: this setting allows to authenticate the client using a JWT signed with an HMAC SHA algorithm, such as HMAC SHA-256. The HMAC is calculate starting from the client_secret. The generate JWT must contains at least the following claims: iss: "<client_id>", sub: "<client_id>", aud: "<identifier of the provider>" and jti: "<JWT unique id>. The JWT must be sent in POST body using application/x-www-form-urlencoded format inside a parameter called client_assertion and also client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer must be present. Also the client_id parameter is mandatory in the request.
    • private_key_jwt: this setting allows to authenticate the client using a JWT signed with a private key. The corresponding public key must be shared between the client and the authorization server. The request and JWT format are the same of client_secret_jwt.

  • Revoke endpoint authentication methods supported: This is the list of supported authentication mechanism to access the revoke endpoint. The available options are the same of Token endpoint authentication methods supported.

  • Introspect endpoint authentication methods supported: This is the list of supported authentication mechanism to access the introspection endpoint. The available options are the same of Token endpoint authentication methods supported.

  • Supported response types: This is the list of response type supported by the authorization endpoint. The possible values are:

    • code: used to return only the authorization code in the authorization endpoint.
    • token: used to return the access token directly in the authorization endpoint. This options is available only, and mandatory, for the implicit grant type.

  • Supported code challenge methods: This is the list of code challenge supported by the Proof Key for Code Exchange (PKCE) flow. Available value are:

    • plain: the challenge is in clear text.
    • S256: the challenge is SHA256 encoded.

  • Scopes: The list of supported scopes by the OAuth 2.0 Provider.

Advanced​

  • Provider endpoints: This is the list of OAuth 2.0 provider standard endpoints. The base path of these endpoints is https://<(new.monokee.com/<domain_id>|<domain-custom-fqdn>)>/oauth2/<provider_id>. This endpoint could be changed if customisation are needed. For example they could be changed with a webhook url that wrap the default behaviour and add some logic. The endpoints are:

    • Authorization endpoint: <base_path>/authorize, it's the url of the endpoint that receives the authorization requests.
    • Device Authorization endpoint: <base_path>/device/authorize it's the url of the endpoint that receives Device Authorization Flow specific authorization requests.
    • Token endpoint: <base_path>/token, it's the url of the endpoint that receives token requests.
    • Revocation endpoint: <base_path>/token/revoke, it's the url of the endpoint that receives token revocation requests.
    • Introspection endpoint: <base_path>/token/introspect, it's the url of the endpoint that receives token introspection requests.
    • Registration endpoint: <base_path>/client/register, it's the url of the endpoint that receives client registration request. It's valid only if Allow self-registration of a client flag in CORE configurations is enabled.

  • Supported response modes: This is the list of response mode supported by the provider. Possible configurations are:

    • query: the response of the authorization endpoint is sent urlencoded to the redirect uri using HTTP redirect method.
    • fragment: the response of the authorization endpoint is sent in a fragment to the redirect uri using HTTP redirect method. This case is useful for web-based clients in which the authorization response must be kept in the user's browser.
    • form_post: the response of the authorization endpoint is sent in a POST body to the redirect uri.

  • Supported languages for the interface: This is the list of languages supported by the provider in the login and consent user interfaces.