SSOGEN / Learn / OIDC vs OAuth: What Is the Difference and Which Do You Use?
Learn
OIDC vs OAuth: What Is the Difference and Which Do You Use?
OAuth 2.0 lets an application call an API, and OpenID Connect adds an ID token on top that tells the application who just signed in.
Updated
OIDC vs OAuth, in one paragraph. OAuth 2.0 (RFC 6749) is an authorization framework: it produces an access token that lets an application call an API. OpenID Connect (OIDC) is a layer on top of OAuth 2.0 that adds an ID token, a signed statement of who just signed in and how.
The two are not competing protocols. Every OIDC sign-in is an OAuth flow with the openid scope added.
- Not a choice. The choice is never “OIDC or OAuth” for the same task.
- The deciding question. Are you signing a user in or calling an API?
Comparison table
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| Main question answered | What may this client do? | Who is this person? |
| Specification | RFC 6749 | OpenID Connect Core 1.0 |
| Built on | Itself | OAuth 2.0 |
| What you receive | Access token, optional refresh token | ID token plus access token |
| Token format | Not specified by the framework | ID token is a signed JWT with required claims |
| Required claims | None defined | iss, sub, aud, exp, iat |
| Trigger | Any scopes your API defines | The openid scope |
| Standard scopes | None | profile, email, address, phone, offline_access |
| Discovery | Not defined in RFC 6749 | /.well-known/openid-configuration |
| Who reads the token | The API (resource server) | The application (client) |
| Typical use | Calling an API, machine-to-machine access | Single sign-on, “log in with” buttons |
Which should you use
Decide by what the application needs to know when the exchange completes.
| You need to | Use | Why |
|---|---|---|
| Log a person in to a web, single-page or mobile app | OIDC | You get an ID token meant for your client |
| Let one service call another with no person present | OAuth client credentials | No sign-in is involved |
| Call an API on behalf of a signed-in person | OIDC to sign in, plus the access token it returns | One flow gives both |
| Give a third-party tool limited access to a person’s data | OAuth authorization code | Scope the token to what is needed |
| Connect a vendor package that only accepts SAML | Neither: SAML | Use what the application supports |
One sign-in, seen both ways
Maria opens Acme Wiki. The wiki needs her email address and read access to a reports API on her behalf. A single redirect serves both.
| Step | OAuth view | OIDC view |
|---|---|---|
| Request | scope=reports.read |
scope=openid email reports.read plus a nonce |
| Browser returns | Authorization code | Authorization code |
| Token endpoint returns | Access token for https://reports.acme.example/api |
The access token, plus an ID token with sub, aud set to acme-wiki and email |
| Wiki uses | The access token as a bearer credential at the API | The ID token to create Maria’s session; the API never sees it |
Without openid in the request, the OIDC column does not apply: the wiki holds a valid access token and no verified identity.
The mistake that makes this matter
A common error is to treat an access token as proof of identity: “the token is valid, so this is Maria.” It is not.
- Access token. It is addressed to an API, not to your application.
- Other clients. A token issued to another client can be valid and still not be a sign-in for you.
- ID token. It carries an
aud(audience) claim naming your client ID and anoncethat binds it to your request. - What to verify. Core section 3.1.3.7 lists the checks.
- The rule. Use the ID token for identity and the access token for API calls, and never substitute one for the other.
The flows are a second source of confusion:
- OAuth defines four grants.
- The current security guidance, RFC 9700, says not to use the implicit grant and never to use the password grant.
- OIDC still describes implicit and hybrid flows, but new applications use the authorization code flow with PKCE.
How SSOGEN handles both
SSOGEN’s OpenID Connect support covers both layers:
- Users. Every sign-in runs the authorization code flow with PKCE
S256; there is no implicit or hybrid flow. The application receives an ID token, and claims such asemailandnameare released only with theemailandprofilescopes. - Programs with no user present. A service application uses client credentials. It receives an access token for the API audiences you name, and the
openid,profileandemailscopes are refused.
In the console, Applications, OpenID Connect lists both kinds.
If the application speaks only SAML, or sits behind Apache and speaks neither, the guide on choosing how to connect an application walks through the questions in order.
Questions people ask
Are OAuth and OIDC the same?
No. OIDC is built on OAuth 2.0 and adds identity. OAuth alone says nothing standard about who the person is.
Is OIDC built on OAuth?
Yes. Its own specification calls it an identity layer on top of OAuth 2.0.
Is OAuth better than OIDC for SSO?
For sign-in, use OIDC; it is designed for that. OAuth is for delegated API access.
What about SAML?
SAML also handles sign-in, mainly for older applications. What is SAML compares them in practice.
Where to go next
- Set up an application. Follow register an OpenID Connect application.
- The sign-in model. Read what is SSO.
- PKCE. New applications use the authorization code flow with PKCE; see what PKCE is.
Sources, all read 2026-10-09: RFC 6749, OpenID Connect Core 1.0, RFC 9700.