What is OAuth?

OAuth is a standard way to give an app permission to use your data in another service. Instead of handing over your password, you let the app hold a token: a kind of spare key that only works for certain things and only for a limited time. The version in wide use today is OAuth 2.0, defined by the IETF, the body that sets many internet standards, in a document called RFC 6749.

OAuth is what runs behind the permission screen you see when you connect a booking tool to Google Calendar, and behind many “Sign in with Google” buttons. Knowing how it works helps you judge what to check on that screen and where to go to take permission back when you no longer need it.

What problem does OAuth solve?

Say you teach an online course and want your booking tool to read your Google Calendar, so students only see the times you’re free. Without OAuth, you might give the tool your Google password. That causes problems, and RFC 6749 lists the same ones in its introduction:

• The tool has to store your password, so if the tool leaks it, your whole account is at risk.
• The tool only needs your calendar, but a password lets it do anything, including reading your email.
• If you want to stop just that one tool, your only option is to change your password, which cuts off every other tool too.

With OAuth, you only type your password on the service’s own sign-in page. The app gets a separate key, called an access token, that has a set scope and lifetime. Think of a hotel key card. It opens your room and nothing else, stops working when your stay ends, and the front desk can switch it off at any time. That’s very different from handing over a master key to the building.

The four roles in OAuth

The OAuth standard describes four roles. Here is how they map to the example above.

Role	What it does	In the example
Resource owner	Owns the data and grants access	You, the course teacher
Client	Uses the data with your permission	The booking tool
Authorization server	Confirms who you are, gets your approval and issues tokens	Google’s account system
Resource server	Holds the data and checks tokens before answering	The Google Calendar API

The authorization server and resource server are often run by the same company. For more on APIs themselves, see What is an API?.

How is access granted?

Most web apps today use what’s called the authorization code flow:

1. You select “Connect Google Calendar” in the booking tool. Your browser goes to a Google page, along with the tool’s name and the scope of access it’s asking for.
2. You sign in on Google’s page, read the consent screen and approve.
3. Google sends your browser back to the tool with a single-use authorization code.
4. Behind the scenes, between its own server and Google, the tool exchanges that code for an access token.
5. The tool calls the Calendar API with the access token and reads only the data you allowed.

The only place you type your password is Google’s page in step 2. The tool never sees it.

Why is there a code in the middle?

In step 3, only the authorization code appears in your browser’s address. RFC 6749 requires authorization codes to be single-use and to expire shortly after they’re issued. The actual key is handed over in the behind-the-scenes exchange in step 4, so it’s much less likely to leak through things like your browser history.

RFC 9700, published in January 2025 to collect current OAuth security advice, goes further. It requires a technique called PKCE (pronounced “pixy”) for mobile apps and apps that run entirely in the browser, and recommends it for web apps with their own server too. With PKCE, the app first creates a secret value and sends only a hash of it, a one-way summary that can’t be turned back into the original. When it exchanges the code, it reveals the original value, and the exchange is refused if the two don’t match. Someone who steals the code on the way can’t use it without the secret.

RFC 9700 also says apps must not ask for your password on their own screens and send it on to the service.

What are scopes and tokens?

Scopes and the consent screen

A scope is the range of access an app asks for, such as “see your events”, “edit your events” or “read your email”. Each service defines its own scopes. The scopes an app requests are listed on the consent screen, and you decide whether to approve. The service can also choose to grant less than the app asked for.

The basic rule is that apps should ask for only what they need, and you should approve only what they need. This idea is covered in more depth in What is the principle of least privilege? For example, if a booking tool that only needs to show your free time also asks to send email on your behalf, stop and find out why.

Access tokens and refresh tokens

An app using OAuth can receive two kinds of token.

	Access token	Refresh token
What it’s for	Sent with each API call to use the data	Getting a new access token when the old one expires
Where it’s sent	The resource server (the API)	Only the authorization server
Lifetime	Usually short	Usually longer (depends on the service)

A refresh token lets an app keep working after an access token expires, without asking you to approve again every time. Whether to issue one is up to the service. Because refresh tokens last longer, apps need to store them with extra care.

How is OAuth different from OpenID Connect?

OAuth itself is about authorization: giving an app permission to use data. It doesn’t define how to authenticate someone, that is, how to confirm who they are and tell the app. An access token says “this holder may use this data”, not who the holder is.

OpenID Connect adds that missing piece as a layer on top of OAuth 2.0. With OpenID Connect, the app receives an ID token. It records which service confirmed which person, for which app and when, and it’s signed so the app can check it hasn’t been altered.

	OAuth 2.0	OpenID Connect
Purpose	Grant access to data (authorization)	Tell the app who signed in (authentication)
What the app receives	An access token	An ID token (plus an access token)
Example	A booking tool reads your calendar	Sign in with Google

Google says the OAuth 2.0 system it uses for signing in follows the OpenID Connect standard. Sign in with Apple also returns an ID token in the same OpenID Connect format. Signing in with a GitHub account works differently: the app uses an OAuth access token to read your GitHub profile.

What should you check before granting or revoking access?

Before you approve, check three things:

1. Make sure the sign-in page’s address belongs to the service, such as accounts.google.com for Google. Take extra care with pages you reached from a link in an email or message, since fake sign-in pages are a classic phishing trick.
2. Read the app’s name and the access it’s asking for on the consent screen. Even on a genuine service’s page, a malicious app can ask for permission. Microsoft calls this consent phishing and advises against trusting an app just because its name or domain looks legitimate.
3. If the access doesn’t fit what the app is for, or you don’t recognize the app, close the screen without approving.

You can revoke access for apps you no longer use in each service’s settings:

• Google: the page in your Google Account that manages connections with third-party apps (Google’s guide)
• Apple: on iPhone, open Settings, tap your name, tap Sign in with Apple, choose the app and tap Delete (Apple’s guide)
• GitHub: under Settings, go to Applications, open Authorized OAuth Apps and revoke the app (GitHub’s guide)

Once you revoke access, the app can’t get new tokens. Depending on how the service is built, an access token issued before you revoked may keep working until it expires. Revoking also doesn’t automatically delete your account or data in the app, so if you want those gone, close your account from within the app.

Summary

• OAuth lets an app use your data through a token with a set scope and lifetime, without your password.
• Most apps use the authorization code flow, and current advice is to add PKCE.
• Scopes define what access is granted, and you decide on the consent screen.
• Sign in with Google uses OpenID Connect, a layer on top of OAuth 2.0, to tell the app who signed in.
• You can revoke access you no longer need in each service’s settings.