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.
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?
The authorization flow 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 creation 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 the authorize endpoint.
- The resource owner authenticates and authorizes the resource access request from the application, and the authorize endpoint returns an authorization grant to the client. The OAuth 2.0 protocol defines four types of grants: Authorization Code, Client Credentials, Device Code and Refresh Token.
- The client then requests an access token from the authorization server by presenting the authorization grant returned from the authorize endpoint along with authentication of its own identity to the token endpoint. A token endpoint is a URL such as https://your_domain/oauth2/token.
- If the client identity is authenticated and the authorization grant is valid, the authorization server or authentication provider -- Google's Authorization Server in this instance -- will issue an access token to the client.
- The client can now request the protected resources from the resource server -- Google Drive in this example -- by presenting the access token for authentication.
- If the access token is valid, the resource server returns the requested resources to the calendar creation 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 may differ slightly. However, it still largely follows these core steps.
Examples of OAuth
OAuth is often used to consolidate user credentials and streamline the login process for users, so that when they access an online service, they don't have to reenter information that many of their other online accounts already possess.
OAuth is the underlying technology used for website authentication by sites that let users register or login using their account with another website such as Facebook, Twitter, LinkedIn, Google, GitHub or Bitbucket. For example, a user clicks on the Facebook login option when logging into another website, Facebook authenticates them, and the original website logs them in using permission obtained from Facebook.
OAuth can also be 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 also often used when a web application requests access to a device's microphone or camera.
OAuth 1.0 vs. OAuth 2.0
OAuth 2.0 is a complete rewrite of OAuth 1.0 and uses different terminology and terms. 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 TLS/SSL (HTTPS) for all communications. OAuth 2.0 access tokens are "short-lived" -- from session-based to a couple 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 towards 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 service provider so the user can access the application. Salesforce and other 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.
Many applications are using OAuth 2.0 for both authentication and authorization, but technically it's only specialized for delegated authorization, not for authentication. 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.
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.