OAuth (Open Authorization)
What is OAuth (Open Authorization)?
OAuth (Open Authorization) is an open standard authorization framework for token-based authorization on the internet. OAuth, which is pronounced "oh-auth," enables an end user's account information to be used by third-party services, such as Facebook and Google, without exposing the user's account credentials to the third party. It acts as an intermediary on behalf of the end user, providing the third-party service with an access token that authorizes specific account information to be shared. The process for obtaining the token is called an authorization flow or grant.
OAuth is primarily designed for authorization. It grants a third-party service access to certain resources associated with a user on another service. It is not designed for authentication, but it can be used to authenticate in some circumstances.
OAuth 1.0 was first released in 2007 as an authorization method for the Twitter application program interface (API). In 2010, the IETF OAuth Working Group published the first draft of the OAuth 2.0 protocol. Like the original OAuth, OAuth 2.0 provides users with the ability to grant third-party application access to web resources without sharing a password. However, it is a completely new protocol, and is not backward compatible with OAuth 1.0. Updated features include a new authorization code flow to accommodate mobile applications, simplified signatures and short-lived tokens with long-lived authorizations.
How does OAuth 2.0 work?
OAuth 2.0 specifies four roles in an authorization flow.
Resource owner. The entity capable of approving access to a resource. This is most commonly a person or end user.
Client. An application requesting access to a resource hosted on the resource server. It can be any type of requestor, including a server, webpage, computer, smartphone, app or IoT device. It will have a redirection endpoint where the authorization server can return an access token.
Resource server. The server that hosts the resource that the client is trying to access. It can respond to requests with a valid authorization token.
Authorization server. The server that accepts the resource owner's approval and issues an access token to the client. It has an authentication endpoint, which is a server that responds to HTTP GET requests for access. It also has a token endpoint where the client requests an access token with its authorization grant.
The authorization code grant in a typical OAuth 2.0 implementation is a six-step process. In the example below, an online calendar creation application needs to be able to access a user's photos stored on their Google Drive:
- The calendar application (the client) requests authorization to access protected resources, in this case image files, owned by the user (resource owner) by directing the user to authorize the client.
- The client makes a request to the authorization server at the authentication endpoint for access to the resource. It will present its client identifier and redirection endpoint.
- The authorization server, in this case the Google login server, authenticates the user and then presents a dialog to the user listing the client and type of access requested. The user sees a prompt that says "Calendar application wants to access your Google Account. This will allow it to read your Google Drive data." The end user approves the access request.
- The client uses the approval to request an access token from the authorization server's token endpoint. The token endpoint then returns an access token to the client's redirection endpoint.
- The client can now request the protected resources from the resource server using the access token, Google Drive in this example.
- If the access token is valid, the resource server returns the pictures to the calendar application (client).
Now the calendar creation application can access and import the user's photos to create a calendar. Depending on the grant type issued in step two, the authorization flow might differ slightly. However, it still largely follows these core steps.
Types of grants on OAuth
OAuth defines several types of grants. Each grant is a different authorization flow that can be used in different circumstances. For example, the way you interact with a webpage to give access might be different than how you interact with a smart lightbulb.
Authorization code grant is the process described above. The client requests an authorization code which is then exchanged for an access token which gives access.
Authorization code grant with Proof Key for Code Exchange (PKCE) is a more secure form of authentication code grant with an extra step to authenticate the client with the authentication server.
Refresh token grant is when the client gets a refresh token from an authorization code grant that can be given to get a new access token to the resource server. This allows the user to only grant access to the client once, and still keep the access token short-lived, requiring regular communication between the client and authorization server.
Implicit grant is a simplified authorization flow that gives the client an access token directly without an authorization grant. It is no longer widely used due to the possibility of abuse.
Resource owner password credentials grant is where the user gives their credentials to a client directly. It is only used in cases where the user trusts the client, such as a desktop or mobile application.
Client credentials grant is where the client can request an access token to resources it controls directly. There is no access to user data. This might be used when two automated services need to exchange information or already have a federated trust relationship.
Device authorization grant is a new authorization flow for devices without a full-featured web browser, such as a smart TV, printer, or other IoT device. It uses another user device to authorize access.
Examples of OAuth
OAuth is used to allow one web service to access protected resources stored with another service -- as in the calendar example above -- or for email authentication so a service can send and receive emails from a third-party account like Gmail, meaning a user can use two different services with only one login. For example, a user's Strava account can access their Garmin Connect account without needing to share their Garmin username and password with Strava.
OAuth is sometimes misconstrued for authentication instead of just authorization. For example, a Facebook game might use OAuth to access a user's account and store its data. Because the user didn't create an account themselves with the game, they think that it is a part of their Facebook account, while in reality, it is a separate account created silently that requests access to their Facebook account each time.
Many applications are using OAuth 2.0 for both authentication and authorization, but technically it's only specialized for delegated authorization, not for authentication. Request for Comments (RFC) 6749 section 3.1. states:
The authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
To illustrate the potential for misuse when OAuth is used for authentication instead of a federated identity management service or protocol, imagine someone needed to verify that a particular house was yours to drop off something when you aren't home. A federated identity might be like giving them your home phone number that they call standing on your porch, they can hear the phone ring inside and maybe hear the answering machine through the closed and locked door. Using OAuth for authentication would be like giving them your house key and they unlock the door and look at your family pictures to prove the house is yours. Giving someone you trust your house key is fine, but you wouldn't do it for a random delivery driver, even if they promise not to take anything.
Although there are many libraries and services that use OAuth 2.0 for authentication, authentication based solely on OAuth is not secure and should be combined with the OpenID Connect standard if developers want to create a secure social login that combines both authentication and authorization.
OAuth 1.0 vs. OAuth 2.0
OAuth 2.0 is a complete rewrite of OAuth 1.0 and uses different terminology. OAuth 1.0's consumer, service provider and user become client, authorization server, resource server and resource owner in OAuth 2.0. OAuth 1.0 does not explicitly separate the roles of resource server and authorization server.
The main changes in function between the two versions include better separation of duties, easier client-side development and end-user experience. OAuth 2.0 offers specific authorization flows for web applications, desktop applications, mobile phones, living room devices and non-browser-based applications such as API-based services.
Desktop and mobile applications no longer need to direct the user to open their browser to the desired service, authenticate with the service, and copy the token from the service back to the application. OAuth 2.0 requires neither the client nor the server to generate any signature for securing the messages. Security is enforced using Secure Sockets Layer (SSL)/Transport Layer Security (TLS) and HTTPS for all communications. OAuth 2.0 access tokens are short-lived -- from session-based to a couple of weeks -- but utilize refresh tokens to acquire a new access token rather than have the user go through the entire process again to reauthorize the application.
Critics of OAuth 2.0 say it is more complex, less interoperable, less useful, more incomplete and most likely to result in insecure implementations. However, it has still become widely adopted throughout the industry.
SAML vs. OAuth
While OAuth is an authorization protocol, SAML (Security Assertion Markup Language) is a federated authentication protocol geared toward enterprise security. It is designed for use in single sign-on (SSO) scenarios, allowing a user to log in to various related systems and services using just a single ID and password.
It implements a secure method of passing user authentications and authorizations between an identity provider (IdP) and a service provider (SP). Examples of identity providers include Microsoft Active Directory and Azure, as they authenticate a user's credentials and return the user authorization to the SP so the user can access the application. Salesforce and other customer relationship (CRM) solutions are usually service providers, as they request authorization from the appropriate identity provider for user authentication.
SAML authorization can also tell the service provider what level of access to grant the authenticated user. SAML is more user-centric than OAuth, which tends to be more application-centric because a user will generally authenticate with each individual service and the application will have a one-to-one mapping with an IdP.
Although SAML uses XML to pass messages and OAuth uses JSON, the real differentiator is that OAuth uses API calls extensively, while SAML uses session cookies. This is fine for accessing certain services during the working day but far less user-friendly for mobile apps, game consoles and IoT devices. OAuth 2.0 client registration is typically a one-time task. Once registered, the registration remains valid, unless the OAuth client registration is revoked.
OAuth vs. OpenID
OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol.
Whereas OAuth 2.0 permits a user of a service to allow a third-party application to access their data hosted with the service without revealing their credentials to the application, OpenID Connect permits a third-party application to obtain a user's identity information which is managed by a service. This functionality makes it easier for developers to authenticate their users across websites and apps without having to own and manage their passwords. Google Plus Sign-In is one platform based on OpenID Connect and OAuth 2.0 that developers can use to provide a secure social login experience for their users.
OpenID Connect is the most popular federated standard built on top of OAuth 2.0. Explore how to use OpenID Connect for authentication. Also, API keys and tokens are two leading methods of access management. Learn the difference between API keys and tokens.
