OAuth 2.0 explained without code

You visit a new app. Instead of creating yet another account, you click "Login with Google". A moment later you are in — the app knows your name, your email, and you never typed a password. It feels seamless, almost magical.

It is not magic. It is OAuth 2.0 — a protocol that has become the backbone of modern authentication. This article explains what OAuth 2.0 is, why it exists, and what actually happens behind the scenes when you click that button.

The problem OAuth 2.0 solves

Imagine you use a third-party app that wants to read your Google Calendar. Before OAuth existed, the only way to do this was to give the app your Google username and password. The app would then log in as you and access whatever it needed.

This approach is obviously dangerous. The app has your full credentials. It can access not just your calendar but everything in your Google account. If the app is compromised, your password is exposed. And if you want to revoke the app's access, the only way is to change your password — which also locks out every other app using those same credentials.

OAuth 2.0 solves this by separating two things that were previously bundled together: authentication (proving who you are) and authorization (granting access to specific resources). Instead of sharing your credentials, you authorize an application to access specific things on your behalf — and you can revoke that authorization at any time without changing your password.

The four roles in an OAuth flow

Every OAuth exchange involves four parties, each with a specific role:

• The user — the person who owns the data and decides what to share. In the "Login with Google" scenario, that is you.
• The client — the application that wants access. The third-party app you are trying to log into.
• The authorization server — the service that authenticates the user and issues tokens. Google's servers in this case.
• The resource server — the service that holds the data the client wants to access. Could be Google Calendar, Gmail, or in a login scenario, just the user's profile information.

The key insight is that the client never talks directly to the resource server without a token. And it never sees your credentials. Everything goes through the authorization server.

What actually happens — step by step

Let us walk through a "Login with Google" flow, step by step:

1. You click the button. The app redirects your browser to Google's authorization server, passing along its own identity (its client ID) and what it is asking for (scopes like email and profile). It also passes a redirect URI — the address Google should send you back to after you approve.

2. Google asks you to log in and consent. If you are not already signed in, Google shows a login screen. Then it shows a consent screen: "This app is asking for access to your name and email. Do you allow this?" You click Allow.

3. Google sends an authorization code. Google redirects your browser back to the app's redirect URI, attaching a short-lived, single-use authorization code to the URL. This code is not a token — it is a temporary proof that you approved the request.

4. The app exchanges the code for tokens. Behind the scenes — server to server, not in your browser — the app sends the authorization code to Google along with its client secret. Google verifies everything and responds with an access token and, in an OpenID Connect flow, an identity token.

5. The app uses the token. The app can now call Google's APIs using the access token. For a login scenario, it calls the UserInfo endpoint to get your name and email, creates a session for you, and you are in.

Scopes — the permission system

One of the most important concepts in OAuth 2.0 is scopes. When an app requests authorization, it specifies exactly what it needs access to. Google might offer scopes like email, profile, calendar.read, or gmail.send.

The user sees these scopes on the consent screen and can decide whether to grant them. An app asking for gmail.send should make you more cautious than one asking only for email. And if you later decide you no longer want an app to have access, you can revoke it from your Google account settings — without affecting any other app or changing your password.

This granular permission model is one of the most powerful aspects of OAuth 2.0. It gives users real control over what they share and with whom.

OAuth 2.0 in your own applications

The "Login with Google" example uses Google as the authorization server. But OAuth 2.0 is a standard — any application can run its own authorization server and implement the same flows for its own users and APIs.

This is exactly what happens when you build a .NET application with an identity server: your server becomes the authorization authority, issuing tokens to your own clients and APIs instead of relying on a third-party provider. The protocol is the same; the infrastructure is yours.

Running your own OAuth 2.0 server

Implementing OAuth 2.0 correctly — the flows, the token exchange, the scope management, the security constraints — requires careful work. IdentitySuite is built on OpenIddict, a certified OAuth 2.0 and OpenID Connect framework for .NET, and handles all of this out of the box. You get a fully compliant authorization server with secure defaults, without writing a single line of protocol-level code.