Table of contents
Start for free
OAuth security vulnerabilitiesOAuth has become a popular standard for login on the web. Does this come at the expense of privacy and security?
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 vulnerabilitiesThere 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.
VerificationSome 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.
ConclusionGoing 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.
Jason GinsbergWhat is end-to-end encryption, and is it secure?End-to-end encryption has become an absolute necessity for messaging and communication today. How does it work?
Andrew MilichWhat is encrypted search?Searching over encrypted data is a unique challenge. What algorithms make it possible?
Skiff TeamIs Google Drive Secure?Google Drive is not end-to-end encrypted. Is it secure?
Skiff TeamIs Google Drive end-to-end encrypted?Over a billion people use Google Drive. Is Google Drive secure, encrypted, and end-to-end encrypted?
Arpeet KaleWhat is a tracking pixel?How do tracking pixels optimize marketing and emails while invading user privacy?
Nishil ShahEmail phishing protectionPhishing is one of the most dangerous email security problems and comes in many forms. How can you protect yourself, your family, and your business?
Andrew MilichEmail security tips for iPhoneIf you’re looking to configure email on your iPhone with privacy and security in mind, check out our tips on using Apple services and Skiff Mail for a secure experience.
Skiff TeamWhat are the best Android privacy apps?Looking to upgrade your messaging, email, and browsing applications to more private alternatives? We’ll list and review the top privacy apps for Android.