OIDC stands for OpenID Connect. It's a standard for authentication that is built on top of the existing OAuth 2.0 framework. While it is often invoked in context within OAuth 2.0, OIDC is distinct in its functionality because it is specifically designed to address authentication as opposed to authorization. In other words, OAuth 2.0 makes it possible for two distinct applications to share user data without providing any information about the who and OIDC makes it possible to share user details.

Getting started with Open ID Connect

When getting started with OIDC, it's important to understand the core concepts and how they fit into the bigger picture:

• OIDC provider: Service that allows users to sign in to multiple applications using the same credentials (usually a username and password). Examples of identity providers include Google, Facebook, and Amazon.
• ID Token: An encrypted JSON object that contains information about the user—their name, email address, and other profile details. It also includes a unique identifier called an "actor ID," which determines if the user has already been authenticated with one of your applications.
• Access Token: Short-lived token that gives your application access to a specific set of resources on the user's account, like their email address or contact information. An Access Token is usually paired with a Refresh Token, which can be used to obtain new Access Tokens if needed. Once you have an OIDC provider and an ID token, you can use them to authenticate users in your application.
• Relying Party (RP): The application that integrates with OIDC. When a user tries to sign in to an RP, they must go through a process called "redirection." Redirection involves sending them from the RP to the identity provider.
• Claims: A claim is a piece of information about the user, like their name or email address. When a user signs in to an application using an identity provider, the identity provider sends a set of claims about the user to the application. The application can then use these claims to identify the user and provide access to the appropriate resources.
• Authorization Server: The server that handles all of the requests related to verifying the Client ID and issuing access tokens. An authorization server can be part of an identity provider or a separate entity. OIDC defines multiple ways authorization servers can communicate with applications, but the most common is "implicit flow." In implicit flow, the authorization server sends an access token directly to the application without first sending a request to the resource server. This kind of communication is well-suited for browser-based applications because it doesn't require the application to keep track of sensitive data, like secret keys.
• Resource Server: Hosts the protected resources users are trying to access. For an application to access these resources, it needs an access token from an authorization server. When a user tries to access a protected resource, the resource server checks to see if the user has an access token or refresh token. If they don't have one, a request is sent to the authorization server asking for one. The authorization server then authenticates the user and issues an access token if everything checks out. Once the resource server gets the access token from the authorization server, it uses it to verify the user has permission to access the protected resource and then grants access accordingly.

Benefits of using OIDC

Much like OAuth 2.0, OpenID Connect has many advantages. These include:

• Robust security: OIDC adds an extra layer of protection via JSON Web Tokens (JWTs). By ensuring data is securely exchanged between parties, you can be assured that your users' information is safe, reducing the likelihood of a data breach.
• Increased flexibility: OIDC allows you to plug in different identity providers easily, should you need to do so. This makes it easy to switch between providers as required without having to make significant changes to your codebase.
• Improved usability: With OAuth 2.0 and OIDC, users no longer have to remember multiple usernames and passwords for different applications. SSO solutions powered by OIDC make it easy for users to log in with just an existing account
• Open standards-based: By relying on open standards, such as JWTs, OpenID Connect helps ensure your application will be compatible with a wide range of identity providers. JSON format also makes data exchange between APIs simple.

Conclusion

OIDC is a well-established, standardized way to add authentication to your app without starting from scratch.

Beyond Identity SDKs can either act as an identity provider by providing OIDC-based authentication or allow developers to federate identities to their existing IDPs using OIDC. You can get started for free with a developer account: https://www.beyondidentity.com/developers/signup