Jan Mikoláš
Glossary
OAuth 2.0
OAuth 2.0 provides delegated authorization for APIs, not user login by itself. OpenID Connect adds a standard identity layer on top of it.
Short definition
Access to an API without sharing the user password.
OAuth separates the user password from third-party application access. A user or service authenticates with an authorization server, which issues the client a limited access token for a protected resource server. The token should have a clear purpose, scope, and limited lifetime.
OAuth does not standardise a single way to prove a signed-in user’s identity, the meaning of business roles, or the shape of an API. An access token may be an opaque value or a JWT; a client must not infer rules from the token format. OpenID Connect handles sign-in through a provider and the ID token.
Use cases
Delegated access to protected resources
OAuth makes it possible to grant limited permission separately from the ordinary password.
- connecting an online store to a marketplace to read orders and write products
- internal applications with API access limited by scopes
- server-to-server synchronisation using client credentials
- renewing a short-lived access token with a protected refresh token
- separating user access from the technical account of a worker
Practical example
Marketplace access for an online store
A merchant connects an online store to a marketplace. The application redirects the merchant to the authorization server with the requested scopes orders.read and products.write. On return, it verifies state and exchanges the short-lived code for a token using the PKCE verifier; it never sees or stores the merchant password.
A nightly inventory synchronisation may have its own client credentials because it does not act on behalf of a particular user. Tokens are stored and rotated as sensitive data, and every marketplace write has its own idempotency protection for retries after a timeout.
How it works
Authorization Code flow with PKCE
The Authorization Code flow is a common choice when a signed-in user is involved; PKCE prevents a stolen code from being redeemed by another client.
- Preparation The client creates state to bind the return to the session and a code_verifier from which it derives an S256 code_challenge.
- Redirect The browser opens the authorization endpoint with client_id, the exact registered redirect URI, scope, state, and challenge.
- Authorization The authorization server authenticates the user and, where needed, obtains consent for the limited scope of access.
- Code exchange The client verifies state and sends the code with the verifier to the token endpoint; a confidential client also authenticates itself.
- Calling the resource The access token is used only with the correct resource server and the minimum required scope.
Key concepts
Who issues a token and who uses it
These terms distinguish the identity, client, and protected resource.
Client, resource owner, and servers
The client requests access, the resource owner may grant it, the authorization server issues tokens, and the resource server protects the API. The client does not have to be a browser.
Scope and token
A scope sets a coarse-grained limit on access, such as orders.read. It does not replace checking whether the client may modify a particular order belonging to a given tenant.
Public and confidential clients
SPAs and mobile apps cannot keep a long-term client secret secure. A server-side application can protect its credentials, but PKCE is a useful safeguard for it as well.
Client Credentials
A flow for a service acting on its own behalf. It does not involve a person signing in or giving consent and must not be presented as a user login.
Benefits and limitations
Limited access without sharing a password.
Benefits
- a third-party application does not need the user password
- access can be limited by scope, target, and lifetime
- a token or refresh token can be revoked separately
- a clear distinction between user and technical access
Risks
- a client secret in a browser or mobile app is not secret
- a loosely checked redirect URI can allow code theft
- failing to verify state permits a forged return
- tokens in URLs, logs, or traces leak credentials
Scope
Choose the flow to match the client type and actual identity.
Authorization Code with PKCE is appropriate for an application acting on behalf of a user. The Client Credentials flow, by contrast, represents a service. Legacy flows that pass a token through the front channel or give an application the user password are not the usual choice for new integrations.
The redirect URI is registered and checked exactly, state is stored with the specific transaction, and access and refresh tokens are never placed in a URL or log. The resource server must still validate the audience, scope, and its own rules for the specific data.
What to consider
A token is a sensitive credential, not a convenient data format.
Security depends on the flow, validation rules, and operational handling of tokens.
- Authorization Code flow with PKCE S256 and verified state
- exactly registered redirect URIs without loose wildcards
- minimum scopes, a limited lifetime, and protection of the refresh token
- no token, code, or secret in a URL, log, or repository
- verification of permission to access the target API even after a token has been issued successfully
Common questions
What OAuth 2.0 is not
Is OAuth 2.0 a login protocol?
No. OAuth provides delegated access to protected resources. OpenID Connect provides standard user login and identity.
Is an access token always a JWT?
No. It can also be an opaque value. A client should treat the token as a credential rather than relying on its format.
Is Client Credentials suitable for user login?
No. This flow represents a client or service, not a user.
Is the orders.write scope enough for every order change?
No. A scope limits the reach of the token; the API still checks the specific tenant, object, and its own authorization rules.
How I approach APIs and integrations in practice
I keep access to an external service separate from ordinary passwords.
For integration interfaces, I address the scope of access, token expiration and renewal, retries, and operational error states.