What Is OAuth? How OAuth 2.0 and "Sign in with Google" Work

What Is OAuth 2.0?

OAuth 2.0 is an authorization framework that lets a user give an application limited, revocable access to data in another service without sharing a password. The app receives a time-limited access token instead of your credentials. It powers most "Sign in with Google" style buttons.

Here is an everyday picture. You arrive at a hotel by car and a valet will park it. You do not hand over your master key, because that key also opens the trunk, the glovebox and the engine. Instead you give a valet key that only parks the car.

OAuth is exactly that valet key idea. Your master key is your password. The valet key is an access token: it works for one job, it expires, and you can cancel it whenever you want.

The IETF published the standard as RFC 6749. OAuth stands for Open Authorization in most sources. We treat what is OAuth as a single-term question, so neighboring concepts get a short mention and a link instead of a full retelling.

How does the valet key analogy answer what is OAuth?

Picture the world before OAuth. A budgeting app wanted to read the bills in your email account. The app asked for your email address and your password, then logged in as you.

That approach had three big problems. First, the app stored your password, so a leak put your whole account at risk. Second, the app could read everything, not just the bills. Third, the only way to cut off access was to change your password, which broke every other app you had connected.

OAuth fixes all three at once. So your password stays between you and the email service. The app receives a token that carries only the permissions you approved. Also, if you change your mind, you remove that one app and nothing else breaks.

So when people ask what is OAuth in one line, the best answer is this: it is a delegation system, not a password system. Keep the key analogy in mind and the later terms will fall into place.

What is OAuth 2.0, and who are its four roles?

Every OAuth conversation uses four roles. Because people mix them up, most documentation feels confusing. The list below maps each role to the valet story.

• Resource owner: the person who owns the data, which means you. In the story, you own the car.
• Client: the application that wants access. In the story, the valet.
• Authorization server: the system that verifies you, collects your consent and issues tokens. In the story, the hotel key desk.
• Resource server: the service that holds the protected data, usually an API. In the story, the car.

In practice, small products often run the authorization server and the resource server in the same company. However, large providers usually separate them. If you want the background on the interface the resource server exposes, our guide to what an API is covers it.

Clients come in two types. First, a confidential client runs on a server and can keep a secret. Second, a public client runs in a browser or on a phone and cannot hide a secret safely. So that difference decides which flow you choose.

How does the authorization code flow work step by step?

The authorization code flow is the most common and most recommended OAuth flow today. The idea is simple: the token never travels through the browser address bar. A short-lived code arrives first, and the app trades that code for a token over a back channel.

1. A user clicks a button such as "Sign in with Google" in the app.
2. Next, the app redirects the user to the authorization server and states which permissions it wants.
3. There, the user proves who they are and approves or declines the request.
4. Then the server sends the browser back to the app's registered address with a short-lived authorization code attached.
5. After that, the app talks directly to the server and exchanges the code for an access token.
6. Finally, the app presents the token to the resource server and receives the permitted data.

Steps four and five matter most. The code works once and also expires quickly. The token never passes through the browser, so it is much harder to leak through history, logs or referrer headers.

For the full wording, read the authorization code section of RFC 6749. For daily work, however, the conceptual flow is usually enough.

What is PKCE and why do you need it?

PKCE, pronounced "pixy," stands for Proof Key for Code Exchange. RFC 7636 defines it. Its goal is simple: even if an attacker steals the authorization code on its way back, the attacker cannot turn it into a token.

The logic works like this. Before starting, the app creates a random secret. Then it sends only a fingerprint of that secret to the authorization server. When the app later exchanges the code, it presents the secret itself. The server compares the two and refuses the exchange if they differ.

So a thief with the code but without the secret gets nothing useful. Think of a parcel locker receipt: only the person holding the receipt can collect the package.

Years ago, teams recommended PKCE mainly for mobile and browser apps. Today, current security guidance recommends it for every client that uses the authorization code flow, including confidential ones. Also, it costs little effort and closes a whole class of attacks.

What are scopes and the consent screen?

A scope is a permission label that says which data and actions an app wants. For example, "read profile" and "add calendar events" are two different scopes. The app lists them in its request, and the provider shows them to you on the consent screen.

A complete answer to what is OAuth must include scopes, because they define the damage a leak can cause. The consent screen is the moment you cut the valet key. Every line you read there turns into a permission written on the token. So you should look at it instead of clicking through.

For developers, the rule is least privilege. If basic profile data is enough to sign someone in, do not ask for contacts or file access. Also, asking for too much lowers user trust and makes a token leak far more costly.

Also, business owners should know one more thing: providers may review scope requests. Sensitive scopes can require extra verification. Check the provider's official developer documentation for the current requirements.

What is the difference between an access token and a refresh token?

An access token is the valet key you show the resource server on every request. We want it short-lived, so a theft has limited impact. A refresh token is a longer-lived, much more sensitive key that you use to obtain new access tokens.

In our story, the access token is the daily valet key and the refresh token is the right to cut a new one. If the first key goes missing, it soon stops working. However, if the second one goes missing, an attacker can keep making new keys, so you must store it with great care.

OAuth does not dictate the token format. Some providers issue opaque random strings. Others, however, issue signed tokens that carry information inside. We cover that signed format separately, and our JWT guide explains structure and validation, so we will not repeat it here.

The practical rule is simple. In practice, never put an access token in a URL, a log or an error message. Also, keep refresh tokens server side in an encrypted store. When a user disconnects the account, invalidate both.

Is authentication the same as authorization?

No, and this is where the most common OAuth misunderstanding starts. Many beginners who ask what is OAuth assume it handles login. Authentication answers "who is this person?" Authorization answers "what may this person or app access?"

OAuth 2.0 targets the second question far more than the first. An access token tells you "this app may read the calendar." However, it does not say "the person in front of you is Alex." So if you treat a plain OAuth token as proof of identity, you build a weak design.

For example, a hotel key card tells the door who may enter, but it does not tell you who carries the card. The card grants access and shows no identity.

For sign-in, OpenID Connect fills this gap. We cover that layer in the next section.

What does OpenID Connect add on top of OAuth 2.0?

In short, OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. The OpenID Foundation site describes the standard and its libraries. Where OAuth gives an access token, OIDC adds an ID token.

The ID token is a signed proof that states who the user is, when and how they signed in, and which app the token was issued for. Then the app verifies the signature and concludes: this session really started at that provider.

OIDC also adds a standard user info endpoint and standard scopes. Profile and email fields arrive under the same names at every provider. As a result, you do not write custom code for each one.

In other words, when you build a "Sign in with Google" button, you technically use OpenID Connect, and OAuth 2.0 is the carrier underneath. If your team plans a social login, the right term is usually "OIDC login."

How do OAuth, OpenID Connect, SAML and passkeys compare?

People mix up these four terms because all of them touch sign-in and access. Still, each one solves a different problem. The table shows the difference at a glance.

The key point is that these are layers, not rivals. A provider can verify a user with a passkey and then use OIDC to hand you the identity. We explain the passkey side in our passkey guide.

SAML is older and relies on XML, so you meet it mostly in enterprise settings. OIDC relies on JSON and fits web and mobile more naturally. If your audience is individual customers, OIDC usually makes the more natural starting point.

What happens behind a "Sign in with Google" button?

Let us follow one visitor from the click to the finished login. Instead of isolated facts, this section joins the earlier pieces into a single scenario. It is an example, not a pixel-exact description of any provider's current screens.

1. The visitor clicks the sign-in button on your site.
2. Your site creates a random state value and a PKCE secret, and keeps both in the session.
3. Next, the browser goes to the provider's sign-in and consent page.
4. There, the visitor proves who they are, reviews the requested permissions and approves.
5. Then the provider sends the visitor back to your site with a code and your state value.
6. Your server checks the state value, then sends the code and the secret server to server and receives the tokens.
7. Finally, your server validates the ID token, matches or creates the user and starts its own session.

First, notice that two separate sessions exist. The provider session and your site session do not depend on each other. Instead, the provider only says "I recognized this person," and you manage your own session from there.

Your site creates the state value in step two and receives it back in step five. If the values do not match, you reject the request. As a result, that tiny check blocks forged redirect attacks.

What are the most common OAuth 2.0 security mistakes?

However, a careless setup opens serious holes, even though OAuth itself is a solid framework. The IETF collected known attacks and defenses in the OAuth 2.0 Security Best Current Practice (RFC 9700). Specifically, below we summarize the mistakes we see most often, in the light of that document.

• Loose redirect address checks: if the registered address and the incoming address do not match exactly, an attacker can steer the code to another address. Demand an exact match and avoid wildcards.
• Requesting broad scopes: unneeded permissions make a leak far more damaging.
• Token leakage: tokens in logs, error screens, URLs or browser storage invite theft.
• Skipping the state value: flows without it stay open to forged requests.
• Embedding a secret in client code: anything shipped to a browser is readable, so you cannot hide a secret there.

Most of these points apply general web security principles to OAuth. For the wider picture, read our OWASP Top 10 guide and the SSL certificate and HTTPS article that explains transport protection.

Why does current guidance discourage the implicit flow?

The implicit flow came with the first OAuth 2.0 release and targeted browser-based apps. It returned the token directly in the address fragment after the user approved. There was no code and no back channel step.

As a result, that design left the token open to browser history, extensions and other scripts on the page. It also made it hard to confirm who the token was meant for. The security best practice document advises against the implicit flow and similar token-returning response types.

What should you use instead? Even for browser apps, use the authorization code flow with PKCE. Your app then stays secure without a server component. If you inherit an older system, disabling the implicit flow belongs at the top of the audit list.

We repeat this because old tutorials and sample projects still show the pattern. Before you copy anything you learned from an older source, compare it with current guidance.

Which OAuth flow should you choose and when?

In short, OAuth is not one flow. It defines several for different client types. So your choice depends on where the app runs and whether a user takes part. The table below speeds up the decision.

RFC 8252 collects best practices for native apps. It also explains why the system browser beats an embedded one.

The old password flow, where the client collects the username and password directly, is also discouraged. It brings back the very problem OAuth set out to solve, which is sharing the password with a third party.

How do you add social login to a business website safely?

Social login shortens sign-up forms and reduces password fatigue. Still, it is not a set-and-forget feature. Below is the checklist our team uses on projects.

• Confirm the need first: which providers do your users actually have accounts with?
• Request only the scopes you need. Email and basic profile are often enough.
• Use the authorization code flow with PKCE and keep the implicit flow off.
• Register redirect addresses with exact matching and separate test from live environments.
• Generate a state value for every request and verify it on return.
• Check the ID token signature, audience and expiry on the server.
• Keep tokens out of logs and store refresh tokens encrypted.
• Give users a way to disconnect and to delete their account.
• Design account merging rules before you trust a provider's email address.
• Keep a backup sign-in path, because a user who loses the provider account loses your site as well.

Also, think about privacy. Your privacy notice must say which fields you collect from the provider and why you keep them. Our guide to building a GDPR compliant website covers the frame. This article is not legal advice, so ask your counsel for binding answers.

Also make sure your sign-in page uses a secure connection. Our SSL checker checks that in seconds. If you also offer password sign-in, the password generator helps your users see what a strong password looks like.

What does social login do for user experience and conversion?

Social login removes friction from the sign-up form. The user does not invent a password, does not wait for an email confirmation and gets in with one tap. On mobile that difference is especially clear.

However, it is not the right answer for every business. Some audiences avoid signing in with a social account. In some sectors users prefer to keep work and private accounts apart. Therefore, offering social login next to email sign-in or a passkey works better than making it the only option.

So do not decide without measuring. Before you launch, track sign-up completion, first action after sign-in and support requests. How you measure depends on your site setup.

We give no numbers here, because results vary a lot by sector, audience and interface. A small test with your own data beats any generic claim.

How does OAuth handle token lifetime and revocation?

The most practical security answer to what is OAuth is that tokens are temporary. An access token expires on its own after a short time. When it expires, the app asks for a fresh one with the refresh token.

The benefit is clear: even a stolen token soon stops working. Refresh tokens carry far more value, so providers protect them with extra rules. For example, a provider can issue a new refresh token on every use, or revoke all of them when it notices suspicious use.

First, revocation works in two directions. The user can remove the app in their provider account settings. The app can also tell the provider to invalidate tokens when it deletes a user or disconnects. Apps that skip this second step keep valid tokens after the user has left.

Default token lifetimes differ between providers. Instead of memorizing a number, read the provider's documentation and set lifetimes according to your own risk level.

What is OAuth used for besides social login?

However, social login is only the most visible use. OAuth shows up wherever an app must reach another service's API on a user's behalf. Sign-in is just one case.

• A calendar app reads meeting invites from an email service.
• Accounting software pulls transactions from a payment service.
• A reporting dashboard reads ad account data with the user's permission.
• An automation tool adds records to a file service for you.

In each case, then, the same idea applies: the user never hands over a password, only a permission for one job. For businesses, that means you can build integrations without asking customers or staff for their credentials.

For server-to-server integrations without a user, you use the client credentials flow. The interface logic behind this is in our guide to what an API is, and the GraphQL versus REST article rounds out the picture on data access models.

Which common misunderstandings should you avoid?

When you study what is OAuth, beginners tend to fall for the same few wrong ideas. So clearing them early makes the documentation and your team meetings easier.

• "OAuth is an encryption method." No, it is a delegation flow. HTTPS protects the data on the wire.
• "An access token proves identity." No, it shows permission, not the person. Identity needs OpenID Connect.
• "Social login ends my security work." No, it only removes password storage. Session handling and token storage remain yours.
• "A library means no configuration." No, redirect addresses and scopes stay your responsibility.
• "OAuth 2.0 and OAuth 1.0 are the same." No, they are different protocols, and 2.0 is the common one today.

In practice, each misunderstanding can turn into a vulnerability. For example, an app that treats a token as identity may accept a token issued for a different app. That is why you should never skip the audience check.

How is a client registered, and what is a client ID?

First, before an app connects to a provider for the first time, it registers. You tell the provider the app name, the app type and the allowed return addresses. In return you receive a client ID. Confidential clients also receive a client secret.

The client ID can be public, like a username for your app. The secret behaves like a password, so keep it in a server environment variable or a secrets manager, and never commit it to the code repository.

Registered return addresses form the most critical field. Providers only send codes to addresses on that list. So keep the list short, and register local test addresses separately from your live app.

Provider dashboards and menu names can change. Therefore, follow the steps in the provider's current developer documentation instead of relying on exact screen names. For domain examples, we only use placeholders such as example.com.

What should a business owner take away from OAuth?

The business version of what is OAuth is simple: it decides whose rules your sign-in follows. Even without a technical team, this concept affects business decisions. You do not need to write code, but you do need to ask the right questions. The questions below help in a meeting with a developer or an agency.

• Which providers will we offer, and why those?
• Which data will we collect, and which fields will we really use?
• Where do we store tokens, and who can reach them?
• What happens when a user wants to disconnect?
• What is our fallback if a provider changes its terms or restricts our access?

However, if the answers stay vague, the integration is not mature yet. Social login ties your business to another company's rules. A provider can change its settings one day, so avoiding total dependence on a single provider is wise.

Finally, data responsibility stays with you. Every personal field you receive from a provider falls under your site's privacy obligations. Collect only what you need and explain the reason to the user.

What is OAuth, and where should you start learning it?

For a newcomer, the most efficient route is to anchor the concept first. Once roles, the authorization code flow and scopes make sense, the protocol details get easier. Then watch the flow in a small test app.

1. Explain the valet key analogy and the four roles in your own words.
2. Draw the authorization code flow on paper and say why each arrow exists.
3. Learn which attack PKCE closes.
4. Read a provider's developer documentation and register a test app.
5. Turn the security best practice document into your own checklist.

In practice, the primary sources are clear enough for technical readers. You do not need to memorize the standards word for word. You only need to know which document answers which question.

If you want to add sign-in or integrations to a product and prefer to hand the work to a team, reach us through our custom software development service. We plan setup, security review and documentation together. If cloud models confuse you, our IaaS, PaaS and SaaS comparison is a good first read.