OAuth Explained: A Guide to Understanding What It Is and How It Works

In today’s digital world, security is a major concern for anyone interacting online.

Have you ever seen a pop-up asking for permission to post on your social media feed, access your smart devices, or share files across different platforms? It’s important to understand how a program, website, or app might authenticate you as a user. Even with automation, you should still be aware of how your data is used or stored.

In a previous article you read about what federated identity is, and how OAuth is one of the technologies used for it. This time, we will go further into understanding what OAuth is and how it works.

What Is OAuth?

OAuth, which stands for Open Authorization, is an open standard authorization framework that enables users to share account information securely with third-party services such as Facebook and Google, without exposing their credentials. An intermediary, the access token, is provided to the third-party service which then authorizes specific user data. This process is referred to as an authorization flow.

The original OAuth was released in 2007 for the Twitter API and provided users with secure access to web services without the need to share passwords. In 2010, the IETF OAuth Working Group published a revised protocol called OAuth 2.0 which had numerous upgrades from its predecessor. It included an authorization code flow specifically for mobile applications, easier signature requirements and tokens with extended authorizations.

How Does OAuth Work?

In basic terms, OAuth is a way to log in without having to enter your username and password. The process can be resumed to four steps:

1. App requests authorization from User.
2. User authorizes App and delivers proof.
3. App presents proof of authorization to server to get a Token.
4. Token is restricted to only access what the User authorized for the specific App.

The main benefit of OAuth is that it’s more secure than traditional login methods. When you enter your username and password into a login form, that information is sent over the internet in plain text. This means that it could be intercepted by someone looking to gain access to your account.

With OAuth, your login credentials are never shared with the app. Instead, they’re only used to generate a unique access token. Since the token is unique to each user and session, it’s much more difficult for someone to gain unauthorized access to your account.

OAuth Components

Now let`s take a closer look at what OAuth consists of:

• Scopes and Consent
• Actors
• Clients
• Tokens
• Authorization Server
• Flows

OAuth Scopes

This is the first key aspect of OAuth. Scopes separate policy decisions from enforcement. OAuth’s permissions are not hidden behind the app layer and have to be reverse engineered. They are often listed in the API documentation: this app requires these scopes.

Depending on the application, consent can differ. You can choose a time range (day, weeks, months), but not all platforms allow you to choose a duration. Furthermore, keep in mind the app can post on your behalf, sometimes even spamming everyone in your network, so watch out when giving your consent.

OAuth Actors

Again, a short list of the actors in OAuth flows would look something like:

• Resource Owner: owns the data in the resource server. The resource owner role can change with different credentials.
• Resource Server: The API which stores data the application wants to access.
• Client: the application that wants to access your data. Clients can be public and confidential. Confidential clients can be trusted to store a secret. They’re not running on a desktop or distributed through an app store. People can’t reverse engineer them and get the secret key. They’re running in a protected area where end users can’t access them. Public clients are browsers, mobile apps, and IoT devices.
• Client Registration
• Authorization Server: The main engine of OAuth.

OAuth Flows

• Implicit Flow – all the communication is happening through the browser. There is no backend server redeeming the authorization grant for an access token. This flow is also called 2 Legged OAuth.

Public clients that run on a browser are best suited to implicit flow. Access tokens are returned directly from authorization requests (front channel only). They usually do not support refresh tokens. It assumes the Resource Owner and Public Client are on the same device. Browsers are the most vulnerable to security threats since everything happens there.

• Authorization Code Flow – uses both the front channel and the back channel. The front channel flow is used by the client application to obtain an authorization code grant. Also known as 3 Legged OAuth.

The back channel is the most secure flow of OAuth since it involves authenticating the Client Application to redeem the authorization grant, and never passes tokens through a user-agent. This is only possible when the Resource Owner and Client Application are on different devices. Apart from Implicit and Authorization Code flows, there are several other flows facilitated by OAuth that may come in suitable for certain purposes.

• Client Credential Flow – the client application is a confidential client that’s acting on its own, not on behalf of the user.

This is a back-channel flow to obtain an access token using the client’s credentials. It supports shared secrets or assertions as client credentials signed with either symmetric or asymmetric keys.

With symmetric-key algorithms, you can decrypt anything as long as you have the password. This is often used for PDFs and .zip files.

Asymmetric cryptography, or public key cryptography, is the use of two types of keys: public keys and private keys. While public keys can be accessed by anyone, private keys are only available to the owner.

• Resource Owner Password Flow – very similar to the direct authentication with username and password scenario and is not recommended.

With this flow, you give the client application a username and password, and the Authorization Server returns an access token. This is for APIs that want to only speak OAuth but have old-school clients to deal with. It usually doesn’t support refresh tokens, and it assumes that the Resource Owner and Public Client are on the same device.

•  Assertion Flow – a more recent addition which is similar to the client credential flow.

This flow enables an Authorization Server to accept authorization grants from third parties, such as SAML IdP. By trusting the Identity Provider, the assertion is used to obtain an access token from the token endpoint. This is beneficial for companies who have invested in SAML or related tech, as it allows them to integrate with OAuth. Since SAML assertions are short-lived there are no refresh tokens; meaning that one will need to keep requesting new access tokens each time it expires.

OAuth Tokens

Using an access token, the client can access the Resource Server. They’re meant to be short-lived. Think about them in hours and minutes, not days and months. You don’t have to use a confidential client to get an access token. Public clients can get access tokens. Since these tokens are short lived and scale out, they can’t be revoked, you just have to wait for them to expire.

To get a refresh token, applications typically require confidential clients with authentication. Refresh tokens are much longer-lived, days, months or even years.

By using your refresh token, you’re getting new access tokens that are then being sent over the wire to all the API resources. Whenever you refresh your access token, it’s a cryptographically signed token. Rotation of keys is built into the system. It is possible to revoke refresh tokens when revoking an application’s access in a dashboard.

Benefits of Using OAuth

When it comes to authorization and authentication, OAuth is becoming the standard. As such, there are many benefits of using OAuth:

1. Increased security: When you use OAuth, your username and password are never shared with the third-party site. This means that even if the third-party site is compromised, your account will remain secure.
2. Convenience: OAuth allows you to access your data on one site from another without having to remember multiple usernames and passwords.
3. Greater control: With OAuth, you can decide which data you want to share with a third-party site. You can also revoke access at any time if you no longer want the third-party site to have access to your data.
4. Improved privacy: When you use OAuth, the third-party site will not have access to your personal information unless you explicitly give them permission.

OAuth 1.0 vs. OAuth 2.0

As we already mentioned in a previous paragraph, OAuth 2.0 is a complete redesign from OAuth 1.0, and the two are not compatible.

OAuth 2.0 is faster and easier to implement than OAuth 1.0, which had complicated cryptographic requirements, only supported three flows, and was not scalable. Additionally, in OAuth 2.0, tokens need not be encrypted on the endpoints since they are encrypted in transit. The 2.0 protocol has six flows for different types of applications and requirements.

OAuth vs APIs

With OAuth, users do not have to go through developer portals like they do with API keys. In most cases, they simply click a button to allow an application to access their account. A standard called OAuth, specifically OAuth 2.0, ensures that these permissions are handled securely behind the scenes.

SAML vs. OAuth

The Security Assertion Markup Language (SAML) is an alternative federated authentication standard that many enterprises use for Single-Sign On (SSO). SAML allows enterprises to monitor who has access to corporate resources.

The greatest difference between SAML and OAuth lies in the security level it provides. SAML is built for use in enterprise networks and uses Extensible Markup Language (XML) to pass messages, while OAuth simplifies the mobile experience by using JSON to exchange data and makes extensive use of API calls which is why mobile applications, modern web apps, game consoles and IoT devices prefer it. On the other hand, SAML uses session cookies in browsers to provide a user access to certain web pages.

OAuth vs. OpenID

OpenID Connect is built upon OAuth 2.0 and provides an identity layer which allows third-party applications to gain access to a user’s managed information hosted by a service, without revealing their credentials. This makes it easier for developers to authenticate their users across webpages and apps without requiring them to own and manage passwords.

Technically, OAuth 2.0 is only specialized for delegated authorization, not authentication, but many applications use it for both.

Examples of OAuth Implementations

When you see a “Login with …” button on a website or app, that’s OAuth at work. When you click that button, you’re giving the app permission to access your public profile and some other information from your Facebook account. There are a lot of different ways you can use OAuth, but here are the most popular:

• Amazon
• AOL
• Bitly
• Dailymotion
• Etsy
• Facebook
• Goodreads
• Google App Engine
• Instagram
• LinkedIn
• Microsoft
• Netflix
• Tumblr
• Twitter
• Vimeo
• WordPress
• Yahoo!

Additionally, OAuth is needed to authenticate and authorize secure access to user profiles on smart home devices. For example, the Nest Learning Thermostat is a service provider that can allow other applications access to the user’s preferred temperatures and home settings. Some third-party applications, like FTL Lights, may want access to this information from Nest to turn your lights on or off, or alert you if your security camera notices unusual movement.

If an application wanted access to this information, it would need to receive a request token and secret from Nest, request authentication from the user and then trade the request token for an access token before ever accessing or changing the home’s environment.

Common Security Concerns with OAuth

OAuth is a popular authentication protocol that allows users to log in to third-party applications using their existing credentials from another service. While OAuth can be a convenient way to sign up for new apps, it also raises some security concerns.

Third-party apps that use OAuth may have access to a user’s personal information, such as their name, email address, and contact list. They may also be able to post on the user’s behalf, which could lead to spam or other unwanted content being shared.

To help protect your security and privacy, it’s important to only use OAuth with apps that you trust. Be sure to read the app’s privacy policy before signing in with OAuth, and only grant the app the permissions it needs to function. If an app asks for more permissions than it needs, consider finding an alternative that respects your privacy more.

Conclusion

OAuth is an essential authentication protocol for many modern applications and understanding it can help make your development process smoother. OAuth is great because it limits the number of third parties who know your passwords. Despite the fact that your personal information is not 100% safe, by reducing the number of entities that have your credentials, they’re less likely to become compromised.

Additionally, OAuth can be combined with Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to further enhance credential authentication security.

If you liked this article, follow us on LinkedIn, Twitter, Facebook, Youtube, and Instagram for more cybersecurity news and topics.

Newsletter

If you liked this post, you will enjoy our newsletter.

Get cybersecurity updates you'll actually want to read directly in your inbox.

I agree to have the submitted data processed by Heimdal Security according to the Privacy Policy

Mihaela Popa

COMMUNICATIONS & PR OFFICER

Mihaela is a digital content creator for Heimdal® and the proud owner of an old soul and a curious mind. Passionate to learn and discover more about cybersecurity, she will gladly share her latest finds with you.