| Name | User readable name for the identity provider client. |
| Enabled | Defines if this idp client configuration is enabled or not. Disabling the configuration disables the endpoint immediately. |
| Issuer | This field is generated after creating the identity provider for the first time.
The issuer address is formed as https://<your_privx_server_endpoint>/oidc/<idp_provider_id>/ where idp_provider_id is generated when saving the idp client configuration for the first time
To see authorize and token endpoints (required by some clients), see well-known endpoint information at https://<your_privx_server_endpoint>/oidc/<idp_provider_id>/.well-known/openid-configuration |
| Client identifier (not visible during creation) | ID of the application that asks for authorization. PrivX server will generate this automatically after saving the configuration. |
| Client secret (not visible during creation) | OAuth 2.0 client secret. Required if PKCE is not enabled. |
| Auth Method Enabled | none, client_secret or client_secret_basic.
If PKCE is enabled, this may be set to "none" to disable the client-secret check. |
| Code Challenge Method Enabled | Enable PKCE with S256 code_challenge_method (described in RFC 7636).
We recommend enabling this setting. |
| Scopes enabled | profile, email, phone, address, offline_access, privx_roles
Specifies which claims the client is allowed to use to access user information. The actual scopes used is the intersection between client's claims and PrivX server's scopes.
Scope openid is implicitly enabled. Scopes like profile and email are often required to fetch users' username or email information.
The offline_access scope allows the client to obtain access tokens that grant access to the Userinfo Endpoint even when the end user is not logged in.
The privx_roles scope allows the client to fetch information about the roles the user currently has. |
| Signature algorithm | Token signature algorithm (RFC 7518).
Allowed values:
- RS256 - RSASSA-PKCS1-v1_5 using SHA256
- RS384 - RSASSA-PKCS1-v1_5 using SHA384
- RS512 - RSASSA-PKCS1-v1_5 using SHA512
- ES256 - ECDSA using P-256 and SHA-256
- ES384 - ECDSA using P-384 and SHA-384
- ES512 - ECDSA using P-521 and SHA-512
- PS256 - RSASSA-PSS using SHA-256 and MGF1 with SHA-256
- PS384 - RSASSA-PSS using SHA-384 and MGF1 with SHA-384
- PS512 - RSASSA-PSS using SHA-512 and MGF1 with SHA-512 |
| Grant Type Refresh Token | Enables refresh_token grant use for the Token Request in the Refresh Token Flow. |
| Auth Method Post | Allow the client to use POST method for client_id/client_secret authentication in addition to HTTP Basic Auth. |
| Default Logout Redirect URI | Default post logout redirect URI to be used, if client calls end_session without defining redirect uri. |
| Allowed Redirect URIs | A list of allowed redirect URIs for Code and Implicit flow. Your callback URI needs to be whitelisted here or the authorization will fail.
One URI per line. |
| Allowed Logout Redirect URIs | Allowed logout redirect URIs for end_session requests.
One URI per line. |
| Access Token Validity | Access-token-validity period in minutes. Default is 5 minutes. |
| Refresh Token Validity | Refresh-token-validity period in minutes. Default is 480 minutes (8 hours). Users are forced to re-authenticate after the refresh token expires. |
| Attribute mapping | Mappings from user attributes to idToken attributes.
By default, PrivX returns users' UUIID in idToken sub field. You can change this by configuring attribute mapping for sub fields.
Syntax:
For example, use email=sub
attribute mapping to return users' email address as user subject in their idTokens' "sub" field.
principal=sub returns users' usernames instead.
Allowed idToken attribute names:
sub, name, preferred_username, family, name, given_name, locale, email, phone_number. |
