SSOGEN / Learn / What Is OAuth 2.0? Roles, Grant Types and Why It Is Not Sign-In
Learn
What Is OAuth 2.0? Roles, Grant Types and Why It Is Not Sign-In
OAuth 2.0 lets an application get limited access to a protected resource with a token instead of the owner's password.
Updated
What is OAuth 2.0? OAuth 2.0 is an authorization framework, specified in RFC 6749 (October 2012). An application (the client) obtains limited access to a protected resource on a user’s behalf by presenting an access token, and never holds that user’s username and password. OAuth answers “what may this application do?”, not “who is this person?”
OpenID Connect answers that second question.
The four roles
RFC 6749 section 1.1 defines four roles. The table maps each one to an example deployment.
| Role | What it is | Acme Corp example |
|---|---|---|
| Resource owner | Whoever can grant access to the resource | Maria Lopez, who owns her calendar |
| Client | The application asking for access | A scheduling tool |
| Authorization server | Authenticates the owner and issues tokens | Acme’s identity provider |
| Resource server | Hosts the protected data and accepts tokens | The calendar API at https://calendar.acme.example/api |
One organization often runs both the authorization server and the resource server, but they remain separate roles with separate checks.
The API validates every token it receives and decides what to allow.
Access tokens and refresh tokens
- Access token. A credential for a specific scope and a short lifetime.
- Token format. The specification does not define it: many access tokens are JWTs, and others are opaque strings that the API validates with the authorization server.
- Refresh token. Section 1.5: it lets the client obtain a new access token without prompting the user again.
- Issuing one. Issuing a refresh token is optional.
- Handling. Keep access tokens short-lived, and protect refresh tokens as you would passwords.
Grant types
A grant is the method a client uses to obtain a token. RFC 6749 defines four, and the security guidance in RFC 9700 (BCP 240, January 2025) changes which ones remain acceptable.
| Grant | Use it for | Status in RFC 9700 |
|---|---|---|
| Authorization code (section 4.1) | Apps with a person present, server-side or single-page | Use it. PKCE is required for public clients and recommended for confidential ones (section 2.1.1) |
| Client credentials (section 4.4) | A program acting as itself, with no person | Use it |
| Implicit (section 4.2) | Was for browser apps | Should not be used; tokens in the authorization response can leak and be replayed (section 2.1.2) |
| Resource owner password credentials (section 4.3) | Was for high-trust clients | Must not be used; it exposes the person’s credentials to the client (section 2.4) |
RFC 9700 adds two more rules:
- Authorization servers must compare redirect URIs by exact string match, so a trailing slash makes a different address.
- An access token should work only at the resource server it was issued for.
The authorization code flow with PKCE
- The client generates a random secret (the code verifier) and sends a hash of it (the code challenge) with the authorization request.
- The person signs in at the authorization server and approves access. The server redirects back to the exact registered redirect URI with a one-time code.
- The client posts the code and the original verifier to the token endpoint. Because the server checks the verifier against the challenge, an intercepted code is useless without the verifier.
- The server returns an access token, and possibly a refresh token.
- The client calls the API with
Authorization: Bearer <token>.
PKCE is defined in RFC 7636. It allows a single-page or mobile app, which cannot keep a secret, to use the code flow safely.
Why OAuth is authorization, not authentication
An access token proves that someone authorized the client to call an API. The standard does not say who that person is, how they signed in or whether they are still present.
- Not a login. A calendar API token was never meant to be read as a login by another application.
- The risk. An application that accepts any valid token as a login can be fooled by a token issued to a different client.
- The fix. OpenID Connect closes this gap with an ID token addressed to the client, with a defined issuer, audience and nonce.
- The rule. Use OIDC to sign a person in, and OAuth to call an API.
See OIDC vs OAuth for a side-by-side table.
What to check when OAuth goes wrong
redirect_urimismatch. This is the most common error. Compare the values byte for byte, including any trailing slash.- Scope not granted. The token is valid, but the API returns 403 because the required scope was never requested or approved.
- Wrong audience. The token was issued for a different API.
- Expired token with no refresh. On a 401, refresh once; if that fails, send the user back through sign-in.
- Secrets in a single-page or mobile app. Public clients should use PKCE and carry no embedded secret.
How SSOGEN handles OAuth 2.0
SSOGEN acts as the authorization server, alongside its OpenID Connect support.
- People. SSOGEN uses the authorization code flow only, never the implicit flow.
- PKCE. Every request carries PKCE
S256, and redirect addresses are exacthttps://values. - Programs with no person present. You register a service application (Applications, OpenID Connect, Register service).
- Service application. It names the audiences (the APIs it may request tokens for) and any scopes you define.
- Authentication. It authenticates with a private key JWT (recommended) or a client secret shown once.
- Token lifetime. The access token lifetime is 5 minutes, 15 minutes (the default), 30 minutes or 1 hour.
- Reserved scopes. The scopes
openid,profileandemailare reserved for people, so service applications cannot request them. - AI agents. For agents calling tools, see OAuth token exchange and MCP authentication.
Questions people ask
Is OAuth 2.0 obsolete?
No. The framework is current, and RFC 9700 (2025) updates its security guidance. Two grants were retired: implicit and password.
Are OAuth and OAuth 2.0 the same?
OAuth 1.0 was a different, signature-based protocol. Today “OAuth” means 2.0.
Is OAuth the same as SSO?
No. SSO means signing in once; OAuth is a way to delegate access. SSO uses OIDC or SAML.
Does OAuth require HTTPS?
Yes. RFC 6749 requires TLS on the authorization and token endpoints.
Where to go next
- Sign-in layer. Read what is OpenID Connect.
- Choosing. Use OIDC vs OAuth to choose between them.
- Console steps. For service applications included, see register an OpenID Connect application.
- PKCE. The PKCE explainer and verifier generator shows each value in the flow (PKCE is RFC 7636).