OAuth is an open authorization standard used to provide secure cross-platform client application access to server resources.
In this definition...
What does OAuth do?
When the standard debuted in 2007, the OAuth authorization framework enabled a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf.
Current OAuth 2.0 standards grant access to APIs and share the extent of user data for other systems. Combined with authentication frameworks, like OpenID Connect, OAuth is able to provide customers and personnel fast and secure access.
OAuth enables server owners to authorize access to the server resources without sharing credentials. This means the user can grant access to private resources from one server to another server resource without sharing their identity.
Portions of this definition originally appeared on eSecurityPlanet.com and are excerpted here with permission.
OAuth terms to know
- Resource Owner: In the OAuth protocol, a resource owner is the user who owns and is authorized to access data stored in an application.
- Client: In the OAuth flow, a client is a third-party application that requests information from the resource owner, such as basic information for registration, or requests users register by logging into another platform like Gmail or Facebook.
- Resource Server: A resource server is a primary application responsible for providing pertinent information from the resource owner to the client application via an API.
- Authorization Server, Grant, and Code: In an OAuth flow, users must confirm consent via the client’s authorization server for the client to access the resource server’s information. If consent is confirmed, an authorization grant with a specific authorization code outlining the request parameter transfers along with the user to the client’s redirect URI.
- Redirect URI: The redirect URI, or callback, is the client page where users land after the client has successfully received the authorization code, allowing them to use the client’s service.
- Tokens: A token is a unique identifier that represents capabilities for authorization via an access token and authentication via an ID token.
- Scopes: Scope, or scoped information, is the parameters of the specific access granted to the client, such as basic profile information or contacts. Developers implement preset scope requests, so when a resource owner initiates the OAuth process, the authorization server knows what information is requested.
What is the OAuth flow?
There are five distinct steps in the OAuth flow.
1. Resource Owner Directed to Authorization Server
A resource owner (user) decides to log in to a new application (client) using another account, such as Gmail or Facebook, which allows them to register without directly inputting their personal information.
The user is then directed to the authorization server to submit credentials, and the client request to the authorization server includes the redirect URI, needed response type, and scope.
2. Credentials Submitted and Consent Requested
After the resource owner confirms their credentials, they must then either grant or deny the client access to specific information, contacts, pictures, and more via a consent authorization. Without consent, the process ends here.
3. Resource Owner Redirect to Client’s Callback
Once consent has been granted, the user is sent to the client’s redirect URI, and an authorization code is sent to the client server to complete the remainder of the process. In this stage, the user believes the registration process has been completed.
4. Client Exchanges Authorization Code for Access Token
The client can now call the resource server’s API with the authorization code, and once the API confirms it is a legitimate authorization code, it will give the client an access token.
5. Resource Server Grants Access
The access token can now be used by the client application to access scoped information when needed, and the resource owner can now access the client application, which now has access to essential information about the user to create the account.
Explore the year’s top DevSecOps Tools.
What are the types of OAuth communication?
When processing an authorization request, OAuth combines both front- and back-channel communication to maximize both user-friendliness and security.
Front-channel communication involves communication between two or more parties that rely on intermediaries like a browser for redirects. In addition, the login and consent pages for this process tend to be more user-centric.
And while front-channel communication presents a vulnerability in the form of an observable protocol, the information involved in the first three steps in the OAuth flow often doesn’t contain sensitive information. Therefore, unauthorized users attempting to inspect a webpage to view confidential information from the publicly visible source code won’t be able to access any confidential data.
Back-channel is when two or more parties rely on a direct connection with standard protocol-level proxies. This communication protocol uses HTTP and API requests server-to-server, meaning the traffic will be SSL (Secure Sockets Layer) encrypted and highly secure.
Because the authorization code is attached to the client server, any attacker would need the server key to attempt to steal the code and exchange it for the access token. This ensures that invaluable tokens are only exchanged for authorization codes by legitimate clients.
What are the benefits of OAuth?
Benefits of OAuth implementation broadly fall under user-friendliness and secure access.
OAuth generally makes logging into applications easier by allowing users to grant access to a limited scope, which is often outlined with standard request language by developers. This can reduce some of the stress and burnout related to repeatedly relogging into multiple applications.
OAuth provides a secure gateway for users and organizations to manage dozens of account credentials with minimal security risks. The nature of limited scope offers structured accountability for information sharing. In addition, OAuth can share data without releasing personal information and utilizes cryptographic SSL encryption to securely save user access tokens on a back channel.
How is OAuth different from authentication frameworks?
Authorization and authentication are possibly the most confused and misused frameworks in networking.
Authorization, which is what OAuth provides standards for, is an invisible process managed by InfoSec (information security) teams that grants users access to resources and manages permissions, usually by exchanging access tokens.
Comparatively, authentication is a more visible process maintained by either a database, biometrics, one-time pins, or application that manages identifying information to confirm user identity, usually by exchanging ID tokens.
The confusion between these frameworks led to OAuth 2.0 being adopted for both authorization and authentication processes. However, since OAuth is designed to address delegated authorization, developers were stuck modifying it to request more information than the authorization mechanism could provide.
The OAuth flow determines if your access token is adequately scoped and legitimate, followed by a grant of access to specific user information. Thus, using it for authentication would prove to be a time-consuming and cumbersome process that would likely produce vulnerabilities.
OAuth solves traditional client-server authentication issues
OAuth is designed to problems and limitations found in the traditional client-server authentication model where third-party applications are required to store the resource owner’s credentials for future use and where resource owners cannot revoke access to an individual third party without revoking access to all third parties.
OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token, issued to third-party clients by an authorization server with the approval of the resource owner.
The OAuth Protocol
The OAuth 1.0 protocol (RFC5849), published as an informational document, was the result of a small ad hoc community effort. The OAuth 2.0 protocol is not backward compatible with OAuth 1.0.
OAuth Security Flaws
In May, 2014 a security flaw was discovered in the widely used OAuth and OpenID website authentication mechanisms. The flaw was not in OAuth 2, but was a result of how some businesses implemented the standards, primary in situations where open redirects were used. Following news of the security flaw, Google said it will be more stringent in securing users when they log in to their accounts by applying additional authorization checks.