For the best web experience, please use IE11+, Chrome, Firefox, or Safari
OneLogin + One Identity delivering IAM together. Learn more
Home / Identity and Access Management 101 / What is OAuth 2.0?

What is OAuth 2.0?

OAuth 2.0 (OAuth2) is an open standard for authorization that enables third-party applications to obtain limited access to user data, hosted by a service provider, without exposing the user’s password. This methodology is important from a security and privacy perspective, as users don’t have to share sensitive data with every service they interact with.

What does OAuth 2.0 authorization mean?

When you authorize an app using OAuth2, you allow it to access specific information or perform certain actions within another service. These permissions, known as scopes, define exactly what the app can and cannot do. For example, you may use OAuth2 to permit application ABC to invoke an API endpoint, access your email contacts or post on your social media account.

This process is all about consent. You, as the user, decide what data or permissions to grant, and the app receives an access token that proves it has been authorized to access these resources. The key thing here is that the app doesn’t get full access to your account – only to the specific things you approve of.

What about OAuth 2.0 authentication?

OAuth2 is purely an authorization protocol, not an authentication protocol. This means that it focuses on granting access and managing permissions, rather than verifying identities. That said, there is a step in the OAuth2 process where an identity server authenticates the resource owner (the user) before granting authorization.

However, this authentication step is outside the scope of the OAuth2 specification itself – it’s just something that must happen prior to authorization.

The difference between OAuth and OAuth 2.0

OAuth 1.0 is the predecessor to OAuth2. Both specifications differ in terms of complexity, security and implementation.

OAuth 1.0 requires the use of cryptographic signatures to verify requests, which makes it secure but also complex to implement. OAuth2, on the other hand, is designed to be more user-friendly. It uses tokens instead of signatures to simplify the process.

OAuth 1.0 relies on a client secret and the signing of each request, which again, makes it secure but also complex. OAuth2 introduces the concept of bearer tokens, which are simpler to use, but can also pose potential security risks if not handled properly. While OAuth2 still uses client secrets for initial authentication, the bearer token can be passed along to the API from the client application with each subsequent request. As long as the token is still valid the client does not need to reauthenticate.

Lastly, OAuth2 is much more flexible than OAuth 1.0. It allows for different types of authorization flows (like the Authorization Code Grant, Implicit Grant, etc.) depending on the needs of the application.

 

Feature

OAuth 1.0

OAuth 2.0

Verification Method

Cryptographic signatures

Tokens

Security vs. Complexity

Secure but complex

Simpler, but potential security risks

Client Secret Requirement

Yes

Optional

Authorization Flows

Limited

Flexible (Authorization Code, Implicit, etc.)

How does OAuth 2.0 work?

Here’s a step-by-step breakdown of OAuth2:

  1. The process begins when the resource owner (end user) wishes to grant a third-party application access to their data. For example, they may need to allow an app to access their Google Drive files.

  2. The third-party application (client) redirects the user to the authorization server (like Google) with an authorization request, which typically includes parameters like response type, client ID, redirect URI (callback URL) and scope in the query string.

  3. The authorization server presents the user with a consent screen to approve or deny the requested permissions.

  4. If the user approves, the authorization server issues an authorization grant, which is usually an authorization code. The authorization code is an encoded string that represents the user's consent.

  5. The third-party application sends the authorization code to the authorization server, along with its client ID, client secret and redirect URI, to exchange the code for an access token.

  6. On the authorization server side, the code is verified, and if everything checks out, an access token (e.g. a bearer token) is issued to the application.

  7. The third-party application makes a request to the resource server (like Google Drive) on behalf of the user. The access token is included in the authorization header to authenticate the request.

  8. The resource server verifies the access token, and if valid, grants access to the third-party app.

What are the OAuth 2.0 grant types?

A grant type is a method for a client to obtain an access token. OAuth2 offers several grant types suited to different scenarios:
What are the OAuth 2.0 grant types?
  1. Authorization code grant
    This is the most commonly used grant type, especially for web applications. It involves a two-step process where the client first gets an authorization code from the authorization server, and then exchanges that code for an access token.

  2. Implicit grant
    The implicit grant is mainly used for single-page applications (SPAs) or mobile apps where the client-side code can’t securely store a client secret. In this flow, the access token is returned directly to the client via the redirect URI; an intermediate authorization code is not needed.

  3. Client credentials grant
    This grant is used when the client itself needs to access resources, not on behalf of a user. It’s quite common in server-to-server interactions where no user is involved. In this flow, the client sends its client ID and client secret directly to the authorization server to obtain an access token.

  4. Refresh token grant
    The refresh token grant is used to obtain a new access token when the original one expires, without the user having to reauthorize. This refresh token may be sent to the client along with the usual access token and can later be used to request a new access token.

  5. Resource owner password credentials grant
    This grant type is used in cases where the resource owner has a high level of trust in the client, such as first-party applications. The user provides their username and password directly to the client, which then sends these credentials to the authorization server to obtain the access tokens.

OAuth 2.0 vs OpenID Connect (OIDC)

OAuth2 and OpenID Connect (OIDC) are often mentioned together, but they are used in different contexts.

As we already know, OAuth2 is an authorization protocol that focuses on granting access to protected resources. OpenID Connect builds on top of OAuth2 and adds an authentication layer. It verifies the user’s identity by using an ID token, which contains information about the user, such as their name and email address.

Conclusion

OAuth2 is the go-to standard for authorization. It provides different grant types to fit diverse application needs and ensures that third-party applications can access resources securely without needing to view or store user credentials.

Try OneLogin for Free

Experience OneLogin's Access Management capabilities first-hand for 30 days
Try It Now