OpenID Connect (OIDC)
What Is OIDC?
OpenID Connect (OIDC) is an authentication protocol that verifies a user's identity when a user tries to access a protected Hypertext Transfer Protocol Secure (HTTPS) endpoint. OIDC was developed to work together with open authorization (OAuth) by providing an authentication layer to support the authorization layer provided by OAuth.
OIDC was developed by the OpenID Foundation, which includes companies like Microsoft and Google. Because OIDC provides both authentication and authorization, it can be used for single sign-on (SSO), delivering the benefits of using one login for multiple sites.
Authentication and Authorization
There are two distinct processes involved when allowing a user to enter a network and use a particular application: authentication and authorization. Authentication means verifying a user’s identity, while authorization means verifying what a user can access. Both are important for SSO, an authentication scheme in which a user does not need to constantly enter their credentials to access multiple applications.
OAuth is an open standard for authorization, compared to OIDC which is an open standard for authentication. OAuth provides third-party applications with limited access to secure resources without compromising the user’s data or credentials. OIDC solves the problem of identity verification when using OAuth. OAuth allows unrelated applications to share user data, but it does not communicate the identity of who is seeking access to those applications.
How Does OIDC Authentication Work?
OIDC is built upon OAuth and is used for authentication. OIDC integrates an identity layer to OAuth using identity (ID) tokens, which are the defining component of the OIDC protocol. OAuth was developed as a solution for delegated access, which allows applications to communicate with one another and exchange information as a proxy for the user, without authenticating or verifying the identity of the user.
OIDC introduces authentication to OAuth by including additional components, such as an ID token, which is issued as a JSON Web Token (JWT). Think of ID tokens as ID cards—they are digitally signed, generated for a particular client, can include requested details such as the user's name, email address, and birthdate, and they can be encrypted.
The access token is not the same as an ID token because it does not contain any identifiable information on the user. Access tokens exist to authorize access to resources, such as applications and servers, on a limited basis.
An ID token is evidence of authentication; an access token is not. This is because ID tokens can only be obtained when the user explicitly gives a client access to whatever information it requests and requires, such as "Sign in with Facebook."
Access tokens can be acquired in several ways without human involvement. For example, when an original access token is invalidated, the client can exchange it for another token, called a refresh token. This automatic exchange between machines does not involve the user verifying their identity—and so access tokens are not proof of authentication.
OpenID Connect Scopes and Claims
Scopes and tokens together represent permission to carry out an action. The token grants permission, and the scope determines what the actual action or behavior is.
OIDC only requires the openid scope. This tells an OIDC-compatible identity provider, such as Microsoft Active Directory or Google, to issue both an ID token and an access token. The ID token contains several user claims, such as sub (subject) and exp (expiry time).
OIDC flows are paths for obtaining ID tokens. The type of flow is dependent on the type of application used, such as browser-based or server-based, and that application's security requirements. There are three common flows.
Authorization Code Flow
This flow type works by exchanging an authorization code for tokens. It is more secure than implicit flows because tokens are not returned directly to the client. This flow is designed for web and mobile applications.
The hybrid flow combines implicit and authorization flows, returning the ID token directly to the client but not the access token. Instead, an authorization code is returned in place of an access token.
OpenID Connect vs. OpenID 2.0
While OpenID Connect (OIDC) accomplishes many of the same objectives as OpenID 2.0, it does so in a way that makes your processes accessible via application programming interfaces (APIs) and suitable for use by both native and mobile applications.
Also, OpenID Connect defines optional solutions for encryption. In addition, while OAuth 1.0a and OpenID 2.0 cannot be merged without an extension, OpenID Connect has OAuth 2.0 features built into its protocol.
Top 3 Roles of OpenID Connect
The roles for standard OAuth and OpenID Connect are nearly identical. The primary difference is that OpenID uses different terms. Here are the top three roles of OpenID Connect:
- Relying party: This is the application that requests user authentication. It is the same as the OAuth client application.
- End user: This refers to the user whose identity is being verified. This is the same as the OAuth resource owner.
- OpenID provider: This is an OAuth service set up to enable OpenID Connect.
How Fortinet Can Help?
OpenID and OAuth are used to strengthen authorization and authentication protocols through SSO. The Fortinet identity and access management (IAM) solution securely manages identity authentication and authorization for all applications in use within the organization. Managing the identity environments across an enterprise's devices and applications can quickly grow into a large administrative burden. Fortinet IAM simplifies this task by providing administrators with a system that controls and manages identity seamlessly.
Fortinet IAM includes FortiAuthenticator, which provides robust, centralized authentication services for the Fortinet Security Fabric. Such services include SSO, certificate management, and guest access management. FortiAuthenticator protects an organization against unauthorized access by authenticating users and devices as they seek entry to the network.