What is OAuth Authentication?
Our guest blogger, David Maayan explains what OAuth Authentication is and how it works
Image by storyset on Freepik
OAuth, an abbreviation for Open Authorization, is an open standard for access delegation. It is commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism allows you to use one set of login credentials (such as username and password) to access multiple applications, enhancing online safety by reducing the number of times you need to enter your login information.
The primary goal of OAuth is to make it straightforward and safe for users to share their online resources. These resources, which include data like photos, videos, contact lists, and more, are often stored on specialized servers. OAuth's role is to provide an authorization framework that allows third-party applications to access this data, with the user's consent, but without exposing their password.
While OAuth itself does not provide authentication, it can work together with other protocols like OIDC to implement an authentication system that enables single sign on (SSO).
How OAuth Works
Let’s review the key components involved in the OAuth process.
Authorization Server
The Authorization Server is the entity that issues access tokens to the client after successfully authenticating the resource owner and obtaining authorization. It is the backbone of OAuth, facilitating the interaction between the resource owner and the client.
Resource Server and Client
The Resource Server hosts the protected user accounts. It can accept and respond to protected resource requests using access tokens. The Client is an application that requests access tokens by presenting its own credentials along with the resource owner's authorization.
Resource Owner
The Resource Owner is typically the end-user who grants permission to the access of their data. The OAuth process allows the resource owner to authorize third-party access to their server resources without sharing their credentials.
OAuth Flow
The OAuth flow is a sequence of steps that the client, resource owner, and server undergo to ensure secure access to resources:
- The process usually begins with the client requesting access to resources controlled by the resource owner but hosted by the resource server.
- The client receives an authorization grant, which is a credential representing the resource owner's authorization.
- This grant is presented to the authorization server, which in turn issues an access token to the client.
- The client can then use this access token to access the protected resources from the resource server.
OAuth Versions
The OAuth protocol has evolved over the years, with two main versions being OAuth 1.0 and OAuth 2.0.
OAuth 1.0
OAuth 1.0 was the first version of the protocol and was relatively complicated to use. It required clients to cryptographically sign their requests, which increased the complexity of the client application. Despite its drawbacks, OAuth 1.0 was a significant step forward in secure and delegated access to resources.
OAuth 2.0
OAuth 2.0 is the latest version of the protocol and is much more user-friendly than its predecessor. It provides specific authorization flows for web applications, desktop applications, and mobile phones. It is more flexible and allows the use of bearer tokens, which means the client does not have to cryptographically sign their requests. OAuth 2.0 also has better support for non-browser clients, making it a more versatile option for modern applications.
Adding Authentication to OAuth: Implementing SSO with OAuth and OIDC
Single Sign-On (SSO) is a user authentication service that allows a user to use one set of login credentials to access multiple applications. SSO simplifies the process for the user and increases security by decreasing the number of times a user must enter their login credentials.
Implementing SSO with OAuth involves using OAuth as the protocol for handling the authorization process. OAuth facilitates the process where a user's credentials are used to access multiple applications, as described earlier. However, OAuth alone does not handle all aspects of user management—it mainly provides the framework for authorization. The OpenID Connect (OIDC) provides the authentication mechanism.
OIDC is a simple identity layer built on top of the OAuth 2.0 protocol, which allows clients to verify the identity of the end-user based on the authentication performed by an authorization server. In simpler terms, OIDC handles user authentication and provides the user's identity to the client application, while OAuth handles the authorization part by providing the client application access to the user's resources.
Here are the steps to implement SSO with OAuth and OIDC:
- User authentication: The process starts with the user trying to log in to an application. The application then sends an authentication request to the OIDC provider, which checks the user's identity.
- Authorization request: If the user's identity is confirmed, the application then requests authorization from the OAuth provider to access the user's resources. The user must approve this authorization request.
- Access token and ID token: Upon approval, the OAuth provider issues an access token and the OIDC provider issues an ID token. The access token allows the application to access the user's resources, while the ID token provides the application with the user's identity information.
- SSO session: The SSO service establishes a session for the user that allows them to access multiple applications without having to log in to each one individually.
By combining OAuth and OIDC, you can create a robust SSO system that provides both user authentication and authorization in a secure and efficient manner. This simplifies the user experience and improves the overall security of your applications.
Best Practices for Implementing OAuth
Secure Transmission
When implementing OAuth, it's crucial to ensure that all data transmission is secure. This is done by using secure transmission protocols such as HTTPS (Hyper Text Transfer Protocol Secure) which encrypts all data sent between the client and the server. This ensures that even if the data is intercepted, it cannot be read or tampered with.
In addition to using secure transmission protocols, it's also recommended to use secure tokens. These are unique strings of characters that are used to authenticate a user, and they should be generated using a secure random number generator. The tokens should also be short-lived, meaning they expire after a certain period of time. This reduces the risk of the token being stolen and used maliciously.
Moreover, it's also important to ensure that the communication between the client and the server is secure. This can be achieved by using Transport Layer Security (TLS), which provides secure communication over a network. By using TLS, you can ensure that the data transmitted between the client and the server is encrypted and secure.
Validate Redirect URIs
Another best practice when implementing OAuth is to validate redirect URIs. A redirect URI is the URL to which the user is redirected after they have authenticated with the OAuth provider. It's crucial to validate these URIs to prevent redirection attacks, where an attacker could redirect a user to a malicious site.
To validate redirect URIs, you should only allow registered and verified URIs to be used. This means that you should have a whitelist of valid redirect URIs, and any URI that is not on this list should be rejected. Additionally, you should also check the redirect URI against the one that was used during the client registration process.
Moreover, it's also recommended to use the "state" parameter in the OAuth protocol. This is a value that is sent in the authorization request and returned in the authorization response, and it can be used to prevent cross-site request forgery attacks.
Limited Scope of Access Tokens
Access tokens are used in OAuth to authorize access to a user's resources. However, it's important to limit the scope of these tokens to reduce the potential damage if they are stolen or misused.
The scope of an access token determines what resources it can access and what actions it can perform. For example, a token might be limited to only reading data, or only accessing certain resources. By limiting the scope of access tokens, you can ensure that even if a token is compromised, the attacker can only access a limited set of resources.
To implement limited scope access tokens, you should define the scope during the authorization request. The scope should be clearly defined and limited to only what is necessary for the application to function. Additionally, the user should be informed about the scope of the access token and give their consent.
Token Storage
The way you store tokens is another crucial aspect of OAuth. Tokens should be stored securely to prevent them from being stolen or leaked. There are several strategies you can use to store tokens securely.
One common method is to store tokens in HTTP cookies. This method is secure as long as the cookies are marked as secure and HTTPOnly. The secure flag ensures that the cookie is only sent over HTTPS, and the HTTPOnly flag prevents the cookie from being accessed via JavaScript.
Another method is to use the Authorization header in HTTP requests. This method is also secure, but it requires more effort to implement as you need to include the token in the header of every request.
Lastly, you can also store tokens in a secure database. This method is the most secure, but it also requires the most effort to implement and maintain.
Use PKCE (Proof Key for Code Exchange) for mobile apps and SPAs
PKCE (Proof Key for Code Exchange) is an extension to OAuth 2.0 that mitigates certain kinds of attacks that are possible in public clients, typically native apps and Single Page Applications (SPAs). PKCE enhances the security of the authorization code flow by adding an additional step in which the client app generates a secret code verifier and its transformed value called code challenge.
When the client redirects the user to the authorization server to get the authorization code, it includes the code challenge. When the client exchanges the authorization code for an access token, it sends the code verifier. The authorization server transforms the code verifier in the same way it transformed the original code challenge, and if the two match, it knows the client app is legitimate.
Conclusion
In conclusion, OAuth is a crucial protocol in today's interconnected digital world that provides a secure framework for access delegation without revealing a user's password. It simplifies the process of granting applications access to user data by using one set of login credentials across multiple platforms. Over time, OAuth has evolved into a more user-friendly and flexible system, with OAuth 2.0 currently offering enhanced features for modern applications.
Adding the OpenID Connect (OIDC) layer to OAuth creates a robust Single Sign-On (SSO) system that handles both user authentication and authorization. SSO not only streamlines the user experience but also enhances overall application security.
When implementing OAuth, adhering to best practices such as ensuring secure data transmission, validating redirect URIs, limiting the scope of access tokens, securely storing tokens, and using extensions like PKCE for public clients can effectively mitigate potential security risks. These strategies help create a more secure, efficient, and user-friendly digital experience. Thus, OAuth, particularly when combined with OIDC, has become a cornerstone in the landscape of secure digital authorization and authentication.
