OAuth security vulnerabilities

OAuth has become a popular standard for login on the web. Does this come at the expense of privacy and security?

Diagram of OAuth login from provider to token to app.

Millions of websites now use OAuth login via Google, Microsoft, and other providers instead of custom built authentication services and accounts. However, OAuth is a complex, decades-old, and somewhat finicky protocol to implement properly, both for OAuth authorization servers, and for client applications that are trying to use it.In this blog, we’ll explore some of the security issues and vulnerabilities for using OAuth. This begins with an introduction of what OAuth is and where you may use it. From there, we will cover how OAuth works for client applications and subsequently how OAuth is implemented for authorization servers.Finally, we’ll look at some upcoming alternatives to OAuth that yield the same simple sign-on methods for authenticating and managing user sessions but lack the vulnerabilities and issues that characterize OAuth’s use today.

What is OAuth?

OAuth’s purpose begins with an incredibly simple paradigm: You do not want to give your username and password to every website. Instead, having a simple way to authenticate, sign in, and manage your account would yield much greater simplicity for users and interoperability of identity. For organizations, this idea also extends to the concept of single sign-on (SSO), wherein a single organization account and identity provider can be used across other services. In this model, one account with an OAuth provider can manage access across an entire ecosystem of enterprise apps.OAuth is a way to securely access information from apps and websites. It allows users to share their data with apps and websites without having to give away their username and password. OAuth is an open standard for authorization developed by a consortium of technology companies and maintained by the Internet Engineering Task Force (IETF); this includes deep technical documentation on how the protocol works and should be implemented, and OAuth Requests for Comment (RFCs), wherein developers lay out proposals and collaborate. Later, we’ll give a deeper overview of how OAuth works with client IDs, access tokens, scopes, and refresh tokens.When you sign in to an app or website using your Facebook, other social media, or Google account, you are using OAuth. OAuth is a type of authentication that allows you to sign in to an app or website using your account from another app or website. When using an OAuth provider, you are giving the app or website permission to access your account via a specific identity provider. The app or website will then have access to the information that you have allowed it to access, which is enumerated in a specific “access grant” and set of scopes.Although OAuth provides a simpler and generally safer way to authenticate than using the same password on every site, it is important to only give access to your account to apps and websites that you trust, particularly as a single identity may now be used across sites. When you sign in with OAuth, you are giving the app or website access to your account. The app or website can then access the information that you have allowed it to access.

How does OAuth work for client applications?

OAuth developer documentation shares specs for how providers can implement an API for authorization and login, and how other product developers can interact with authorization servers to perform login.When a user tries to access a resource that is protected by OAuth 2.0, they are first redirected to a login page where they enter their credentials. Once the user is logged in, they are redirected back to the resource they were trying to access and are given an access token. This access token is used to authenticate the user when they make future authorization requests to the resource. For developers the redirect that users are sent to after authenticating is known as a redirectURI, which developers typically must configure for security. Stay tuned for more information about how redirect URIs can yield dangerous security properties.There are two main types of access tokens: Bearer tokens and refresh tokens. Bearer tokens are short-lived and can be used to access resources without the need for a refresh token. Refresh tokens, on the other hand, are long-lived and are used to generate new bearer tokens when they expire. For example, if you use a service and expect to stay logged in for weeks, it is possible that the service is using a combination of bearer tokens and refresh tokens to stay logged in.The OAuth 2.0 authorization framework defines four different grant types: Authorization code, implicit, resource owner password, and client credentials. The authorization codegrant type is the most commonly used and is used when a user is trying to access a resource that they have not previously granted access to. The other grant types (formatted in JSON) are used in specific circumstances that are enumerated more in the OAuth standard and RFCs. Developers can indicate the desired response type by using the response_type parameter in an initial OAuth post request.When a user is redirected to a login page, they are typically presented with a list of the resources that they are trying to access and are asked to grant the application permission to access those resources, such as a user’s name, email address, birthday, or more information. The application attempting to authenticate will supply a client secret, which is used to tell the authorization server the identity of the requesting application (which will have configured additional parameters, like redirect URLs and expected origins). Once the user grants the application permission, they are redirected back to the application with an authorization code.The application then uses the authorization code to request an access token from the resource server’s token endpoint. The access token is used to authenticate the user when they make future requests to the resource.There are a few different ways that the access token can be used to authenticate the user. The most common way is for the application to include the access token in the authorization header of future requests to the resource. This header could indicate both that a user has logged in and provide a link to relevant information, such as a profile picture and name.Another way to authenticate the user is to use a refresh token. Refresh tokens are long-lived and can be used to generate new access tokens when they expire. Developers can implement logic to store and use refresh tokens to query an OAuth2 provider for additional tokens.The final way to authenticate the user is to use a client credentials grant. With this grant type, the application requests an access token from the resource server using only its own credentials. This grant type is less common and is typically used by applications that need to access resources on behalf of the user.

OAuth security issues and vulnerabilities

There are a few basic security rules to follow of when using OAuth:1. OAuth should only be used over HTTPS to prevent third-parties from intercepting requests and gaining access to sensitive data.2. Care should be taken when using OAuth with third-party applications. It is important to trust the third-party application and to understand what data it will have access to.3. Users should be made aware of what data is being shared with a third-party application and should be able to revoke access at any time.4. When using OAuth, users rely on a single provider for their identity around the web.There are also various protocol problems that yields OAuth limitations. As an example, if some OAuth providers do not limit redirect URIs after authenticating, it is possible that a malicious redirectURI could send a user to an unfriendly location after redirecting.Furthermore, redirect URIs are typically a poor fit for non-web applications, such as mobile apps, where a redirect URL will open a user’s browser instead of staying inside an application. This type of attack is known as an open redirect.

Additional security considerations

Phishing is one of the most serious issues facing OAuth users. Phishing is a type of online scam where malicious actors or hackers impersonate a legitimate organization; for example, if attackers created a fake Google login page to convince people to submit their username and password. After a user is redirected to a fake OAuth login page, losing the username and password to a major online account (Google, GitHub, Facebook, or others) could lead to complete identity theft for victim users.Clickjacking is a type of attack where the attacker tricks a user into clicking on a button or link on a page that they did not intend to click on, such as an unintended OAuth authorization form. This can be done by hiding the button or link under a fake button or link that the user does intend to click on. Once the user clicks on the button or link, the attacker can then do whatever they want, such as redirecting the user to a malicious site, stealing their information, or installing malware on their device.Clickjacking can be used to attack any website or web-based application, and is especially dangerous because it is very difficult for users to detect. Attackers can also use social engineering techniques to make their clickjacking attacks even more effective. For example, they may create a fake login page that looks identical to a legitimate login page, and trick the user into entering their credentials. Or, they may send the user a phishing email that contains a link to a fake website that looks identical to a legitimate website. If the user clicks on the link, they will be taken to the attacker's website instead of the legitimate website, and the attacker can then do whatever they want.Clickjacking is a serious security threat, and users need to be aware of it in order to protect themselves. When browsing the web, users should be cautious of clicking on any links or buttons, especially if they are not familiar with the website. If users suspect that they may be a victim of clickjacking, they should report it to the website owner or administrator so that they can take steps to protect other users. Clickjacking can lead to similarly serious identity theft consequences as users’ personal information is exposed.Cross site scripting (XSS) is another major security vulnerability that can endanger OAuth users and providers. XSS enables attackers to inject malicious code into webpages viewed by other users. When a user views a page, the malicious code is executed by their browser, resulting in the disclosure of sensitive information or execution of undesirable actions on the user’s behalf, without their knowledge or consent. XSS vulnerabilities can be divided into two main types:Reflected XSS: This type of attack occurs when malicious javascript is injected into a web page and is then reflected back to the user’s browser. The browser then executes the script, resulting in the disclosure of sensitive information or execution of undesirable actions on the user’s behalf. For example, this could involve modifying how an OAuth application works, changing access grants, modifying or inserting callbacks, or simply exfiltrating a user’s OAuth tokens.Stored XSS: This type of attack occurs when a malicious script is injected into a web page and is then stored by the web server. When a user views the page, the malicious script is executed by their browser, resulting in the disclosure of sensitive information or execution of undesirable actions on the user’s behalf. XSS attacks can be used to steal cookies, session IDs, and other sensitive information, as well as to inject malicious javascript that will be executed on the user.Cross site forgery (CSRF): Cross site forgery attacks, also known as CSRF or XSRF, are a type of attack that tricks a user into performing an action on a website that they did not intend to do. This can be done by embedding malicious code into a webpage that is then executed by the user's browser without their knowledge. The code can then perform actions on the website that the user is logged into, such as changing their password, making a purchase, or transferring money.CSRF attacks can be particularly malignant in the OAuth context, as they could involve unintentionally sending data to a target server, such as an authorization code that can be used to obtain a user’s access token and refresh token (which then provide access to all available resources on a user’s account). The PKCE extension to OAuth, detailed in this RFC, proposes mitigations to the protocol to increase resistance to CSRF.

Verification

Some OAuth providers, like Google and Dropbox, now validate other websites for security. For example, in order to add access to certain elements of Google user data, Google must review developers’ OAuth flow for possible attack vectors. Without reviewing apps, scopes, and grants, service providers could conceivable implement wide ranging grants, such as for users documents on Dropbox or Gmail email content, that could expose millions of users to data loss and exfiltration.

What’s better than OAuth?

Currently, few login methods provide an ideal balance of security and convenience. For example, using a username and password can provide a frustrating user experience, and using email-only based login methods can have serious security issues and limited functionality.Other applications choose to manage user sessions with JWTs (JSON Web Tokens) - signed tokens created by a server to prove access for a particular user or context. JWTs have no formal structure or spec for authorization; in contrast, OAuth details a clear specification for servers and client apps.One alternative that crypto-focused companies are exploring is using crypto wallets to authenticate, which allows a user to sign an attestation proving that they own a particular crypto address. For example, Skiff is an email, collaboration, and file storage product that allows for a crypto wallet for login. This limits the security issues that end users face and exposes no user data. However, crypto wallets are often a target of exploitation, and also require passwords or other authentication methods.

Conclusion

Going forward, a combination of crypto wallet login, tightly implemented OAuth protocols, and hardware login techniques (such as facial or finger biometrics) will likely compete for the most prevalent login mechanisms. However, due to many different security issues, OAuth providers have become increasingly limited as they centralize user data and still present significant possibilities for identity theft or security flaws.