Innomerc Learn
English is the default.
Identity & Access

OAuth Explained

Follow delegated access from a client to an authorization server without sharing the user’s password.

Foundational6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

OAuth lets an application obtain limited access to another service on your behalf. A fictional calendar helper can request permission to read your calendar without asking you to give it your calendar password. You review the requested access at the provider.

The grant should match the task. A read-only calendar helper should not need permission to delete your mail. You can later review and revoke connected applications, although existing tokens may follow the provider’s revocation behavior.

Technical explanation

Under the hood

In an authorization-code flow with PKCE, the client prepares a verifier and challenge. The authorization server authenticates the user and obtains any necessary consent, then redirects an authorization code to a registered callback. The client exchanges the code and verifier for tokens.

Access tokens are intended for a resource server and may be opaque or structured. OAuth is about delegated authorization. OpenID Connect adds an identity layer, including an ID token for the client. The two tokens have different audiences and must not be confused.

Practitioner explanation

Practitioner perspective

Use exact redirect validation, PKCE and the security properties appropriate to the client. Protect authorization responses from injection and cross-site request forgery, and implement refresh-token protection according to the client and server model. Avoid obsolete flows when current best practice provides safer alternatives.

Examine consent, scope escalation, token audiences, application registration and revocation. Monitor unusual grants and refresh activity. OAuth does not repair excessive privileges in the resource API; each API operation still needs permission checks.

See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

Identity and access mechanisms

Compare the evidence exchanged, rather than treating every mechanism as a password replacement.

Steps1. Consent 2. Code 3. Code + PKCE 4. Access token 5. Bearer token
Click a box or choose its name to learn what it means.
User / clientReadyIdentity serviceReadyApplicationReadyAuthenticatorReadyUser / clientReadyIdentity serviceReadyApplicationReadyAuthenticatorReady
Ready to traceOAuth delegation
Before you start · 5 stepsOAuth delegation

OAuth grants scoped access; it is not by itself a login protocol.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • User / client

    A person, or the software acting for them, beginning a sign-in or access request.

    Example: You select Sign in and your browser starts the request.

  • Identity service

    A system that checks identity and manages sign-in decisions.

    Example: It checks a password and may require an additional authentication factor.

  • Application

    Software that carries out a task for its user.

    Example: A timetable app looks up the next bus departure.

  • Authenticator

    A device or method used to prove control of an authentication factor.

    Example: A security key or an authenticator app helps verify a sign-in. Methods have different protections against phishing.

OAuth delegation

OAuth grants scoped access; it is not by itself a login protocol.

  1. User / client Identity service: Consent. The user authorizes a scoped client request.
  2. Identity service User / client: Code. The redirect carries a short-lived authorization code.
  3. User / client Identity service: Code + PKCE. The client exchanges the code with the required verifier.
  4. Identity service User / client: Access token. The authorization server issues a scoped token.
  5. User / client Application: Bearer token. The resource server validates the token and operation permissions.

OpenID Connect

OIDC adds an identity layer to OAuth flows.

  1. User / client Identity service: Sign in. The provider authenticates the user in a protected flow.
  2. Identity service Application: ID token. The client receives an ID token through its configured OIDC flow.
  3. Application User / client: Local session. Issuer, audience, signature and flow binding checks precede a session.

Passkey

The authenticator signs a challenge scoped to the relying party.

  1. Identity service User / client: Challenge. The relying party creates a fresh challenge.
  2. User / client Authenticator: User verification. The authenticator verifies the user under its policy.
  3. Authenticator Identity service: Signed assertion. The assertion binds the challenge and relying-party context.
  4. Identity service Application: Identity established. A valid assertion establishes the authenticated session.

SAML federation

A service provider validates a signed assertion and its intended recipient.

  1. User / client Application: Sign in. The service provider starts a federated sign-in.
  2. User / client Identity service: Authenticate. The identity provider authenticates the user.
  3. Identity service Application: SAML assertion. The service provider validates signature, audience, recipient and time.
  4. Application User / client: Session. The application establishes its own session.

Mutual TLS

Both peers prove control of certificate-associated private keys.

  1. User / client Application: ClientHello. TLS negotiation starts.
  2. Application User / client: Server proof. The client validates server certificate and handshake proof.
  3. User / client Application: Client proof. The server validates client certificate and handshake proof.
  4. Application User / client: Protected channel. Application authorization still applies above the channel.

Magic link

A short-lived, single-use link relies on access to the delivery inbox.

  1. User / client Identity service: Request link. The user asks for a sign-in link.
  2. Identity service Authenticator: Email link. The link is delivered to the registered inbox.
  3. Authenticator Identity service: Redeem. The service checks expiry and consumes the token once.
  4. Identity service Application: Session. A local session is established under policy.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Client requests access

Cedar Calendar Helper requests a limited calendar scope.

1 / 5

Takeaway The helper receives delegated access, not the user’s password.

Read every step without animation

Delegated access

  1. Client requests access. Cedar Calendar Helper requests a limited calendar scope.
  2. Provider checks user. The user signs in at the authorization server.
  3. Authorization code. A short-lived code returns to the registered callback.
  4. Code + PKCE verifier. The client exchanges the code with its verifier.
  5. Resource API. The access token reaches the intended API for a permitted action.

The helper receives delegated access, not the user’s password.

Attack view

A code delivered to the wrong client or callback can undermine the grant. This conceptual journey highlights redirect and code-exchange boundaries without exercising a real provider.

Defender view

  • Use authorization code with PKCE and current OAuth security guidance.
  • Request minimal scopes and keep client secrets out of public clients.
  • Validate each token at its intended recipient and protect refresh tokens.

Common mistakes

  • OAuth alone is not a standardized identity assertion to the client.
  • An access token is not necessarily a JWT.

Check your understanding

Which protocol adds a standardized identity layer to OAuth?
Active recall: explain this idea in 30 seconds

OAuth lets an application obtain limited access to another service on your behalf. A fictional calendar helper can request permission to read your calendar without asking you to give it your calendar password. You review the requested access at the provider.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Web and application security
From passwords to identity security
Professional reference

Back to topic