Introduction
Configure a Service Provider that uses the OAUTH or OpenIDConnect Protocol for authentication and/or authorization.
IDHub will act as an (intermediary) Identity Provider for the Service Provider.
General Settings
Field | Description |
---|---|
Display Name | User defined name of the Service Provider |
URL | Not used |
Description | User defined description of the Service Provider |
Authentication Scheme | Defines which IDP(s) that can authenticate a user for this Service Provider, and how the user can authenticate. |
Type | "OAUTH Client" |
Subject | Primary user attribute that is used to identify the user. |
Client ID | This is a generated ID that uniquely identifies the Service Provider. The client has to provide this ID with a secret before it can access the Service Provider. Because IDHub acts as an Identity Provider, it generates the Client ID and Secret. The Client ID and Secret is only generated when the Service Provider is initially created. Note that the secret is only showed once. If you didn't save it, it is lost. Then you can only generate a new Client ID and Secret (making the old ones obsolete immediately). |
Callback URL's | After a user successfully (or unsuccessfully) authorizes an application, IDHub will redirect the user back to the URL provided in the Authentication Request. This Callback URL provided in the Authentication Request must be defined (whitelisted) as a Callback URL in IDHub. The whitelisting is required, because information is sent to the callback URL. This is sensitive information that should be sent only to accepted domains. |
Scopes | Defines which scopes IDHub can allow the user to authorize for this Service Provider. To use the OpenIDConnect protocol instead of the OAuth Protocol, the "openid" scope MUST be allowed on this SP. For more information on the field, see below |
Client Profile | Defines if the client can securely store a secret. When this is set to "Public" a PKCE (Proof Key for Code Exchange) is required. |
Authorization Code Flow Enabled | Allows IDHub to provide Authorization Code Grants Authorization Code Grants should be used when there is an actual user that can be asked to log in and approve access for the client. |
Client Authentication Enabled | Allows IDHub to provide Client Credentials Grants Client Credentials Grant are used in a machine-to-machine context, when there is no user to complete the log in procedure or to provide authorization. In this case the client will simply authenticate itself. |
Implicit flow enabled | Allows IDHub to provide Implicit Grants. Implicit grants are intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret because all of the application code and storage is easily accessible. |
Token Exchange Grant enabled | Enables the use of a JWT Bearer Grant Type. This grant allows the client to exchange access tokens. In 9.4 and earlier versions: we only trust our own IDP's originating tokens. From 9.5 onwards, it's possible to use tokens from other IDP's; which includes SAML Assertions. |
Token Exchange Allowed IDP's | Enabled when 'Token Exchange Grant enabled' is checked. This defines all the IDP's which are trusted; if the client provides a valid access token or assertion from this IDP; it will be accepted to exchange with the Token Exchange grant. |
Token Exchange Policy Workflow | Enabled when 'Token Exchange Grant enabled' is checked. This policy workflow can be used to define additional business logic to restrict token exchange logic, for example by querying an external system. More information on the Token Exchange Policy Workflow [LINK] here |
JWT Bearer Grant enabled | Enables the use of a JWT Bearer Grant Type. This grant is used when the client wants to receive access tokens without transmitting sensitive information such as the client secret. This can also be used with trusted clients to gain access to user resources without user authorization. |
Resource Owner Credential Grant enabled | Allows the usage of a Resource Owner Credential grant. This grant is used for trusted first party clients both on the web and in native device applications. |
Access Token Type | Defines the type of Bearer Token that is dispensed. Supported types:
|
Access Token Time To Live | Defines the duration of how long the access token remains valid after dispensing it. |
Refresh Token Enabled | Allows IDHub to dispense Refresh Tokens. A refresh token can be used to obtain a new Access Token, without asking the user to log in again. |
Refresh Token Time To Live | Defines the duration of how long the refresh token remains valid after dispensing it. |
ID Token Time To Live | Defines the duration of how long the ID Token remains valid after dispensing it. |
Client Authentication Type |
|
Cross Origin Request | Specify additional domains from which Cross-Origin Requests are accepted. Eg. *.trustbuilder.com to allow access from all subdomains from trustbuilder.com. |
Audience | Additional Audience(s) that this ID Token is intended for. The Client ID of the Service Provider is applied as an audience automatically. |
Issuer | Defines who issues the ID Tokens. If left empty, the default https://domainname.ext/idhub/oidc is applied. |
JWKS URL | Instead of defining a trust certificate for the public keys of the client, it's possible to provide a JWKS url, where the current key can be fetched. This key is used to validate the signature of the JWT bearer token (Client Authentication Type must be set to "Private Key JWT" |
Certificates
Certificates are managed at Certificate Overview.
It is still possible to import certificates without needing to leave the Service Provider screen.
Field | Description |
---|---|
Context |
Defines what the certificate is used for. There is only one option: Key - Signing: Used to sign messages to the SP |
Certificate Alias | The alias of the certificate to use for this context. |
Used From | Defines from when this certificate may be used. These periods may not overlap for "Key - Signing" certificates. |
Used Until | Defines until when this certificate may be used. |
Allowed Scopes
Field | Description |
---|---|
Name | Name of the scope, as defined in "scopes" Click the checkbox before the name to enable or disable this scope. |
Type | OAuth: Defines which API's (method & URL) the client is given authorization for. OpenID: Contains a set of attributes that can the user can authorize the IDP to include in the ID Token. To use the OpenIDConnect protocol instead of the OAuth Protocol, the "openid" scope MUST be allowed on this SP. |
Description | User defined description of the Scope |
Is Default | If no scopes are specified in the request, authorization for this scope is requested by default. Multiple scopes can be marked as default. |
Comments
Please sign in to leave a comment.