OpenID Connect Standards
On this page
OpenID Connect introduces a large number of capabilities that are used for many scenarios and across many industries.
The Curity Identity Server enables the use of a wide range of identity-related standards. It supports a growing list of OAuth, OpenID Connect, SCIM and related protocols from standard bodies such as IETF, OpenID Foundation and OASIS. The OpenID-related standards that the Curity Identity Server supports are listed below:
| Standards Area | Summary of Behavior |
|---|---|
| OpenID Connect Core | The core authentication behavior is built on top of OAuth 2.0, along with ID tokens, and claims to communicate information about the end-user in a digitally verifiable way. The core standard defines how identity providers (IdPs) authenticate users and issue tokens, allowing relying parties (RPs) to access identity data securely. In addition to required behavior, optional features include Pairwise Pseudonymous Identifiers (PPID), the Claims Parameter and Self-Issued OpenID Provider (SIOP) support. |
| Discovery | The interoperability mechanism for relying parties to dynamically discover the end-user's OpenID Provider, understand its supported features, and obtain information needed to interact with it. The Curity Identity Server supports issuer discovery via WebFinger for relying parties to discover its server settings. |
| Dynamic Client Registration (DCR) | The interoperability mechanisms enable an approved relying party to securely and dynamically register as an OAuth client, with no manual setup steps. The Curity Identity Server supports multiple forms of authentication for a client to get an initial access token with a dcr scope to register securely. Pre-processing before issuing the DCR access token is customizable via script and can be used to make additional region-specific checks if needed, in regulated industries such as banking. |
| Dynamic Client Registration Management (DCRM) | The means for self-service management for clients using a registration_access_token and registration_client_uri as defined in OpenID Connect Registration. In addition, the Curity Identity Server also supports the IETF DCRM specification. |
| Multiple Response Types | This specification defines an authorization request parameter for the response mode that informs the authorization server about which mechanism it should use for returning the authorization response from the authorization endpoint. |
| Form Post Response Mode | A mechanism to return sensitive OAuth fields to the relying party via an HTML form that is automatically submitted. This ensures that the authorization code is excluded from the browser history and server logs. |
| 3rd-party Initiated Login | An initiate_login_uri endpoint can be registered against a relying party, so that a third party can use this endpoint to perform an IdP-initiated login. This mechanism also supports deep links, where a target_link_uri is verified by the relying party before allowing the request. |
| Session Management | A mechanism for the relying party (RP) to monitor the user's session at the identity provider (IdP). It enables a relying party to automatically log out the user locally if they log out from the identity provider. |
| Front Channel Logout | A logout mechanism in OpenID Connect where the identity provider (IdP) communicates with relying parties (RPs) using the user's browser. This method relies on rendering an iframe or redirecting the user to notify all connected applications that a logout event has occurred. |
| Back Channel Logout | A server-to-server logout mechanism in OpenID Connect where the identity provider (IdP) notifies Relying Parties (RPs) about a logout event without relying on the user's browser. |
| CIBA | The protocol refers to initiating authentication on one device and then completing it on another. This enables scenarios such as a call center operative asking a remote user to authenticate then using the end-user's claims in the call center app. |
| CIBA FAPI | A financial-grade profile providing recommendations when using CIBA decoupled flows to protect high-worth data. This mandates the use of confidential clients, signed authentication requests, and additional claims, which may include those related to geolocation. |
| FAPI Security Profile 1.0 - Part 1 | The Financial Grade API (FAPI) baseline profile is a set of requirements and best practices when protecting data. Key features include use of strong authentication by confidential clients via mutual TLS or client/user assertions and the use of Proof Key for Code Exchange (PKCE) by public clients. |
| FAPI Security Profile 1.0 - Part 2 | The Financial Grade API (FAPI) advanced profile requires further development effort to protect high-worth data once the baseline profile has been implemented. This includes using the request or request_uri parameters with the authorization code flow, accepting only JWTs with the strongest encryption algorithms, and using only sender-constrained access tokens. |
| FAPI 2.0 Security Profile | A high-security profile that provides requirements based on an attacker model for protecting APIs that expose high-value data. Though it was originally designed for financial applications, the FAPI 2.0 Security Profile is suitable for any scenario with high-security demands. |
| Health Relationship Trust Profile (HEART) | A set of requirements that increases baseline security and improves operability in a manner specifically applicable to (but not limited to) the healthcare domain. Advanced options include the use of JWT assertions for client authentication and accepting only Proof of Possession access tokens in APIs. |
| JWT Secured Authorization Response Mode | Ensures that authorization response data is tamperproof. It does this by packing it together into a JWT. This JWT can be signed so that the client application can integrity-check it. It can also be encrypted. These protections provide safeguards against untrusted intermediaries. |
The following links provide further background about OpenID certification:
Standards & Conformance
Visit the following link to view all supported standards: Complete list of supported standards.
Future Standards
Curity is always actively working on supporting newer parts of the OpenID Connect framework. If you're missing a specification or have questions contact us for more details.
Jacob Ideskog
Identity Specialist and CTO at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
