About OAuth 2.0 and OpenID Connect
Overview
This page explains the differences between OAuth 2.0 and OpenID Connect and gives you some tips on how to use them in your app. The terms OAuth 2.0 and OpenID Connect (OIDC) are commonly used in web applications that need to authenticate and authorize users. These are two standards for web authorization, but they are not the same.
OAuth 2.0: the authorization framework
With OAuth 2.0, a third-party application—a client—can access resources on behalf of a user—a resource owner—from a resource server, such as an API). The user grants the client a limited access token, which the client uses to request resources from the resource server. The access token is issued by an authorization server, which verifies the user's identity and consent. For different scenarios of authorization, OAuth 2.0 defines four roles (resource owner, client, resource server, and authorization server) and four grant types (authorization code, implicit, resource owner password credentials, and client credentials).
OpenID Connect: the identity layer
OpenID Connect is a newer standard that extends OAuth 2.0, adding support for authentication. With OpenID Connect, a client can verify the user's identity and obtain basic profile information. The user logs in to an identity provider (such as Sky Mavis) using OpenID Connect, and the identity provider returns an ID token to the client. The ID token is a JSON Web Token (JWT) that contains information about the user, such as their name, email, and picture. In addition, the client can request an access token and a refresh token from the identity provider. The access token and refresh token can be used to access other resources.
Differences between OAuth 2.0 and OpenID Connect
| OAuth 2.0 | OpenID Connect |
|---|---|
| Focused on authorization—granting access to resources. | Focused on authentication—verifying the identity of a user. |
| Doesn't offer a standard way to obtain user information. | Offers a standard way to retrieve user information. |
| Uses access tokens—opaque strings that can only be validated by the resource server. | Uses ID tokens, which are self-contained and can be validated by the client. |
| Flexible and can be used for various types of apps. | More specific in nature, can be used for single sign-on (SSO). |
How to choose between OAuth 2.0 and OpenID Connect
Choosing between OpenID Connect and OAuth 2.0 depends on your app's goals and needs. If you want to access resources from a resource server on behalf of a user, but don't care about the user's identity or profile, OAuth 2.0 is sufficient. You can choose a grant type that fits the architecture and security requirements of your app. If you need to verify the user's identity and obtain basic profile information, OpenID Connect may be a better choice. You can use the OpenID Connect authorization code flow or the implicit flow. Both are based on OAuth 2.0, but return an ID token along with an access token.
Tips for using OAuth 2.0 and OpenID Connect
- Use HTTPS for all communication between the client, the authorization server, the resource server, and the identity provider.
- Use PKCE (Proof Key for Code Exchange) to prevent authorization code interception attacks.
- Use
stateandnonceparameters to prevent CSRF (Cross-Site Request Forgery) and replay attacks. - Validate the access token and the ID token according to their respective specifications.
- Store the access token and refresh token securely in the client.
- Respect the scope and expiration of the access token and the ID token.
- Keep your client and server libraries up to date.