This article gives a brief overview of the OpenID Connect standard and its main benefits.
A world of libraries and communities exist when using open standards. In security it’s is rarely a good idea to invent a protocol yourself.
By using standard integrations, developers can focus on business value instead of security. You don’t have to worry about dependencies to proprietary integration packages and SDKs.
Over time, new standards will emerge, and will have to be supported, if and when this occurs, already using a standard will make the transition to new standards smoother.
OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. It specifies an extensible suite for client and end-user identity interaction that allows web, mobile, and script clients to request and receive information about authenticated sessions and end-users as well as providing access to backend APIs using OAuth 2.0 tokens.
This allows an identity provider to provide clients with end-user identification and basic profile information. The specification is available at https://openid.net/specs/openid-connect-core-1_0.html.
OpenID Connect is the leading Internet standard for cross domain single sign-on and identity. It uses JWTs (JSON Web Tokens) as identity token format and extends OAuth 2.0 flows that work for the web, mobile apps and mobile browsers.
The main benefit of using OpenID Connect is that it provides a completely standardized set up, with no additional surprises. Since it is built on OAuth 2.0 it is API ready, but adds the missing pieces in OAuth so that the client can know who logged in, how strongly etc.
OpenID Connect doesn’t itself define how authentication should be performed but it provides a standardized protocol on how to ask for authentication, and how the result of authentication should be presented to the client.
OpenID Connect is API ready, since it is based on OAuth 2, already a great standard for providing authorization with a good set of flows, that OpenID Connect expands on.
The response format and sometimes the request formats are based on JSON.
JSON Web Tokens (JWT pronounced jot) is a JSON-based open standard for creating tokens that assert some number of claims. It consists of claims encoded into a JSON object.
The tokens are signed or encrypted, allowing all parties in possession of the key to be able to verify that the token is legitimate. Depending on type of keys and algorithms used JWTs can be secured against tampering, eves dropping and non repudiation.
OpenID Connect is a protocol designed to support mobile applications. It works well in both mobile apps and web apps. It supports mobile single sign-on.
OpenID Connect allows you to dispense with managing and distributing certificates or other methods requiring even greater amounts of overhead. The protocol provides a key distribution mechanism called JSON Web Key Set (JWKS).
With OpenID Connect, it is easy to separate different login domains, completely avoding crossover between domains.
OpenID Connect provides endpoints for Clients to use when they need access to user data. It also provides mechanisms for the user to consent before this data is released to the client.
With the Curity Identity Server, you get a Single Sign-On solution with all the benefits of the OpenID Connect standard, but also offers expanded features based on these standards, with a clearly implemented Neo-Security Architecture.
The Curity Identity Server does provide the standard OpenID Connect benefits for SSO, but also enables a range of other options that further improve the SSO experience and security.
Since you are sharing the SSO session between domains, it makes sense to also make that clear to the user through a unified user experience. In the Curity Identity Server, this is automatically enabled through the configuration.
In the Curity Identity Server you can define in detail not only how to share the SSO session, but also specify which other data to share, allowing for differentiated security based on which client is making requests.
In the Curity Identity Server, it’s possible to run an OpenID Connect flow in a secure iframe. This means that the frame is only embeddable from the sites that have been pre-configured in the Curity Identity Server. Any other attempt to embed the frame will cause the frame to not load or to break out.
This makes it possible for organizations keep the user on the same site even when authenticating.
Not only does the Curity Identity Server support SSO but it also supports all single logout mechanisms defined in the OpenID Connect standard, giving you the perfect tools for ensuring that SSO is securely cleaned up.
For more information, see the Curity Developer Portal.