Identity Provider Types: OAuth 2.0

Introduction

Configure Identity Providers that use the OAuth 2.0 Protocol (or the OpenIDConnect protocol, which extends the OAuth 2.0 protocol) to authenticate and authorize users.  

IDHub will act as a Service Provider when sending an Authentication Request to the Identity Provider.

Settings

Field Description
Display Name User defined name for the Identity Provider
URL Not used, strictly for informational purposes
Description User defined description for the Identity Provider
Provisioning Workflow Select a workflow that will be executed after the Authentication is complete. Said workflow can be used, for instance, to provision users in a user database.
Type "OAuth 2.0"
Subject Attribute that is used to identify the Subject
Well Known The URL where the IDP's metadata (discovery endpoint) can be retrieved.
App Client ID The "client_id" as it is known at the IDP.  Identifies IDHub as the Service Provider.
Authorization Endpoint URL where to request the Authorization Code token
Token Endpoint URL where to send the ID Token request
Token Endpoint Method

There are four options to authenticate the Client (Mind: Not the user!):

  • Client Secret Basic: The client is authenticated via basic http authentication, using the client ID and secret. A textbox is displayed where the client secret must be provided.
  • Client Secret JWT: The client is authenticated by passing the client ID and secret in a signed JWT. The audience (identifies the authorization server as an intended audience) and secret must be supplied. [RFC: Link]
  • Client Secret Post: The client is authenticated via http post authentication,  using client ID and secret, which are sent as parameters alongside the other parameters. A textbox is displayed where the client secret must be provided.
  • Private Key JWT: Rather than using a secret, this method uses the "Key Signing" Private Key to sign the Client Authentication JWT. The Audience (identifies the authorization server as an intended audience) must be provided.
User Info Endpoint URL where to request the User Info
JWKS Endpoint The URL where the Identity Provider's JWKS (Key information) can be found.
Expected Issuer Used in OpenID Connect. The value filled in here must match the "iss" (issuer) value that is given in the id_token. This value is validated when using in the Authorization Flow and Hybrid Flow, so it's highly recommended to provide this value.  If this cannot be validated, this will result in an INVALID_GRANT.

We will also use this value as "audience" in the authentication request.
Attribute Name for Subject Defines which attribute in the Authentication Response JSON describes the subject.  This is because the Identity Provider does not necessarily use the same attribute as the subject.
Scopes Define which scopes to include in the Authentication Request.
Add an "openid" scope if the "OpenIDConnect" Protocol is used.
More information on Scopes: here
Sign Authn. Request When this is enabled, the Authentication Request to the IDP will be signed, using the signing key certificate.
Encrypt Authn. Request When this is enabled, the Authentication Request to the IDP will be encrypted as a JWT, using the public encryption key of the IDP.  This key is generally retrieved from the JWKS endpoint.

The following extra fields are displayed when this is enabled:
  • CEK encryption algorithm (Content Encryption Key algorithm - Asymmetric)
  • Content encryption algorithm (Content Encryption algorithm - Symmetric)
Request by Reference This is similar in behavior as the SAML artifact: instead of returning the claims in the id_token, the SP will retrieve the claims from the uri that is passed in the "request_uri" parameter.
This is only used in OpenIDConnect.
Client Mode

Defines which Authentication protocol is used.  OAuth 2.0 or OpenIDConnect

Flow Type Defines which flow is used (more information below):
  • Authorization Code:
    Flow in which an Authorization Code is returned from the Authorization Endpoint and all tokens are returned from the Token Endpoint. 
  • Hybrid:
    Flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint. 
  • Implicit:
    Flow in which all tokens are returned from the Authorization Endpoint and neither the Token Endpoint nor an Authorization Code are used.  

Determine which flow type to use

The table below is intended to provide some guidance on which flow to choose in particular contexts.

Flow type behavior

How each Flow behaves

Flow Type OAuth OpenID
Authorization Code 1. IDP provides an authorization code.

2. The authorization code is used to get an access Token which authorizes the client.

3. Claims are requested separately via the UserInfo Endpoint.
1. IDP provides an authorization code.

2. The authorization code is used to get an ID Token (which also contains the claims)
Hybrid Not available in OAuth 1. IDP provides an access token and an ID token.

2. All information and claims are retrieved from the ID token.
Implicit 1. IDP provides an access token.

2. Claims can be requested via the UserInfo Endpoint, by presenting the access token.
1. IDP provides an access token.

2. Claims can be requested via the UserInfo Endpoint, by presenting the access token.

Certificate

Certificates are managed at Certificate Overview

It is still possible to import certificates without needing to leave the Identity Provider screen.

Field Description
Context Defines what the certificate is used for.
  • Key - Signing: Used to sign the Authentication Request to the IDP, in case of a "Private Key JWT"  (See "Token Endpoint Method").
  • Key - TLS: Used to initiate a secure connection (TLS) to the IDP
  • Trust - TLS: Used to accept a secure connection (TLS) from the IDP

Certificate Alias The alias of the certificate to use for this context.
Used From Defines from when this certificate may be used. In some cases these periods may overlap for the same context (eg. during a certificate renewal), but in other cases they may never overlap (Key - Signing, Key - TLS).  
Used Until Defines until when this certificate may be used.

Well-known URL

OpenID Connect defines a discovery mechanism, called OpenID Connect Discovery, where an OpenID server publishes its metadata at a well-known URL, typically:

https://server.com/.well-known/openid-configuration

This configuration endpoint is a good start to configure your IDP.

For IDHub, this URL path is:  

https://{server}.{com}>/idhub/oidc/.well-known/openid-configuration


Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.