OAuth

What is OAuth in simple words

OAuth (Open Authorization) is an authorization protocol that allows one application to get access to your data on another service without transferring your login and password to it. Instead of a password, the application receives a special temporary access key (token).

In simple words, OAuth is like a digital pass that you give to a guest so that he can enter your apartment, but only into the hallway, not into all rooms. You do not give him the keys to all doors (your password), but only a special one-time pass with limited rights.

A classic example is the “Sign in with Google” or “Sign in with VKontakte” button on any website. You press the button, you are redirected to the Google page, where you enter your password (but not on a third-party site!), confirm access, and the site receives only what you allowed — for example, your name and email. Your password remains secret.

OAuth solves the main problem of old systems — before, applications asked for your login and password from another service, which was extremely unsafe. If the application turned out to be fraudulent, you lost access to the entire account. OAuth gives only limited access to specific data for a certain time. According to Okta, more than 80% of all corporate applications use OAuth for authorization, and the number of OAuth tokens issued daily is in the billions.

Read about how OAuth is related to the security of web applications in the article Information security.

How OAuth works

The OAuth process can be imagined as obtaining a digital pass. Four parties participate in it:

• Resource Owner: This is you — the user who owns the data and gives permission.
• Client: A third-party application that wants to get access to your data (for example, a mobile application or a website).
• Authorization Server: The server that verifies your identity and issues tokens (for example, Google Accounts, GitHub).
• Resource Server: The server where your data is stored (for example, Google Drive or the VK profile API).

The process looks like this:

1. You press “Sign in with Google” on a third-party website.
2. The site redirects you to the Google server, where you enter your password.
3. Google asks: “Do you allow this site access to your name and email?”
4. You press “Allow”.
5. Google issues a temporary code to the site and redirects you back.
6. The site exchanges the code for an access token.
7. The site uses the token to request your data from the Google API.

Read about how tokens work in the article Security token.

OAuth 2.0 grant types

OAuth 2.0 supports several authorization flows (grants), which are selected depending on the type of application (web, mobile, server) and the level of trust:

• Authorization Code Grant: The most common and secure flow for web and mobile applications. The client receives an authorization code, which it then exchanges for an access token. The code is transmitted through the user's browser, and the token — through a secure channel between the client server and the authorization server.
• Implicit Grant (deprecated): A simplified flow for single-page applications (SPA), where the token is returned directly to the browser. It is considered less secure and is not recommended in modern practice.
• Resource Owner Password Credentials Grant: A flow where the user transfers their login and password directly to the client. Used only for trusted applications (for example, official mobile applications of banks). A high-risk method.
• Client Credentials Grant: Used for server-to-server interactions where there is no user. The client authenticates with its credentials (client ID and client secret) and receives a token for accessing protected resources.

Choosing the right grant is a critically important step in designing application security. The wrong choice can lead to vulnerabilities and data compromise.

OAuth 1.0 vs OAuth 2.0

OAuth 2.0 is a modern version of the protocol that replaced OAuth 1.0. The main differences:

• Simplicity: OAuth 2.0 is significantly simpler for developers. Complex cryptography for signing requests is not required (in OAuth 1.0 you had to generate a digital signature for each request).
• Flexibility: OAuth 2.0 supports different use cases: web applications, mobile applications, browserless devices (IoT), server-to-server interactions.
• Tokens: OAuth 2.0 uses access tokens and refresh tokens, which allows extending access without re-entering the user's credentials.
• Security: OAuth 2.0 supports HTTPS transmission to protect tokens and relies more on TLS for security.

Today OAuth 2.0 is the de facto standard for authorization on the internet. It is used by Google, Facebook, GitHub, Microsoft, Yandex and thousands of other services. Read about how OAuth integrates with APIs in the article Infrastructure.

OAuth security

Despite the fact that OAuth is a secure protocol, there are risks that are important to consider when using it:

• Token interception: If an attacker intercepts an access token (for example, through an unsecured connection or a Man-in-the-Middle attack), he can use it before it expires. Using HTTPS is mandatory.
• Phishing: Attackers can create fake login pages that imitate the authorization server to steal credentials. It is important to always check the URL before entering a password.
• CSRF attacks (Cross-Site Request Forgery): Attacks in which an attacker forces the user to perform unwanted actions on a site where he is authorized. To protect against them, the state parameter is used in OAuth requests.
• Client secret compromise: If an attacker obtains the client secret (the application's secret key), he can impersonate a legitimate application. Store the client secret in a safe place.

To enhance security, it is recommended to use a short lifetime for access tokens (for example, 1 hour) and refresh tokens to extend the session without re-entering the password. It is also important to use PKCE (Proof Key for Code Exchange) to protect against interception of the authorization code in mobile applications.