Support of OAuth 2.0/OpenID Connect Specifications

The following sections reference which sections of the OpenID Connect and OAuth 2.0 specifications are supported by ActivID Appliance.

Supported Response Types

The ActivID Appliance server’s authentication endpoint only supports the Authorization Code Flow (defined in the OpenID Connect Core specifications - section 3.1) with the code response type.

It does NOT support the following response types that are associated with the implicit and hybrid flows:

• id_token token
• code id_token
• code token
• code id_token token

Supported Grant Types

The ActivID Appliance server supports most of the core OAuth 2.0 grant types and also some HID specific ones. The server can be configured to accept only a subset of these, either for the entire provider or on a per client basis.

The following grant types are supported:

• Standard OAuth 2.0 grant types:

  • Authorization code (authorization_code) – obtained from the authentication endpoint (see section 3.1.3 of the OpenID Connect Core specification)

  • Resource owner password credentials (password) – see section 4.3 of the OAuth 2.0 specification

  • Client credentials (client_credentials) – see section 4.4 of the OAuth 2.0 specification

  • Refresh token (refresh_token) – the client uses a refresh token to renew an access token without end-user interaction (as defined in section 12 of the OpenID Connect Core specification).

    For further information, see Configuring Support for Refresh Tokens.

• Proprietary grant types:

  • Client secret PKI (urn:hid:oauth:grant-type:client-secret-pki) – the client authenticates itself via a mutual TLS (mTLS) authentication connection to the token endpoint with the client certificate which is registered as a ActivID Appliance PKI credential during manual client registration (using the ActivID Management Console) or dynamic client registration.
    For further information, see Configuring Client PKI Authentication.

The following standard OAuth 2.0 grant types are NOT supported:

• Implicit (used only in the implicit flow which is not supported)

OpenID Connect Authentication Request Parameters

The ActivID Appliance server supports the following authentication request parameters that are mandatory for OpenID Connect providers.

• Supported OAuth 2.0 parameters:

  • response_type

  • client_id

  • scope

  • redirect_uri

  • state

  • request

• Supported OpenID Connect parameters:

  • nonce

  • max_age

  • login_hint

  • acr_values

  • code_challenge

  • prompt

  • id_token_hint

  • request_uri

Supported Client Authentication Methods

The ActivID Appliance server supports the following standard client authentication methods that are based on a provider-issued client secret:

• client_secret_basic – basic HTTP authentication with client secret (static password, OTP, activation code, etc) where the parameters are sent in the Authorization header as base64-encoded string

  It is the least secure method.

• client_secret_post – basic HTTP authentication with client secret where the parameters are sent in the request body as form parameters

• private_key_jwt – authentication with JWT signed with client private key

The ActivID Appliance server supports TLS mutual authentication as a client authentication method:

• [HID Custom] client_secret_pki – authentication via server validating the client PKI certificate on the TLS connection
  (This is the HID custom method, for legacy use.)

• self_signed_tls_client_auth – authentication via server validating the client PKI certificate on the TLS connection

Supported ID Token Algorithms

The ActivID Appliance server supports JSON Web Signature (JWS) protected ID Tokens:

• RS256 – the ID Token is signed with the provider’s RSA JWK

Supported Claim Types

The ActivID Appliance server issues normal claims. Aggregated and distributes claims, asserted by a claims provider other than the OpenID provider, are NOT supported.

Offline Access

The ActivID Appliance server supports offline access, that is, the exchange of valid refresh tokens for new access, optionally id, and refresh tokens between the client application and the IdP without the user being prompted.