OAuth 2.0 and OIDC: roles and token purpose

Understand delegated access without confusing it with user identity.

UnderstandStudy an examplePractise

Understand the concept

OAuth 2.0 is a framework for delegated access, not by itself a protocol proving a user’s identity to a client. Separate resource owner, client, authorisation server and resource server. A client can request limited access to an API on someone’s behalf, while the API validates tokens according to its own contract.

OpenID Connect adds an identity layer. An ID token describes authentication to the client; an access token enables resource-server access. An API should not accept an ID token as an access-token substitute. Discovery, issuer metadata and UserInfo participate in the provider’s model.

An authorisation code is a short-lived exchange artefact, not an API credential. Tokens need not be JWTs. Draw actors and token destinations explicitly, including which party validates what, to expose callback and secret-handling mistakes.

WHEN TO USE IT

When designing federated login and external API access.

COMMON PITFALL

Using an ID token as an API access token.

01 / PRACTICE

One topic. Three levels of depth.

HTTP / illustrative example

Client → authorization server: request delegated access

An access request, not the API operation itself.

This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.

02 / YOUR TURN

Try it yourself first.

You received an ID token from Google. Can you send it as Bearer to any API?

Show the solution and explanation

Worked solution

No: use the API’s accepted access-token contract.

No. Issuer, audience and token purpose must match the API contract.

RasimAtaberkŞahin

Understand the concept

One topic. Three levels of depth.

Try it yourself first.