Authentication vs Authorization: Differences and Examples

Authentication and authorization answer two different questions. Authentication asks, "Can you prove who you claim to be?" Authorization asks, "Are you allowed to perform this action?"

For example, signing in with a password is authentication. Being allowed to open the admin dashboard after signing in is authorization. Signing in successfully does not automatically give you permission to do everything.

Authentication vs Authorization: Quick Answer

Authentication normally happens before authorization in a protected application, but authorization is not a one-time gate only at login. APIs typically validate the request's credentials or access token and make an authorization decision for each protected request. A service account or API client authenticates too — not only human users.

For broader IAM vocabulary, see What is IAM?.

Authentication: Proving Who You Are

Authentication checks whether a user or system can prove that it controls the account it claims to be using — for example, with a password, security key, or certificate.

Authentication can use one or more authenticators, for example:

• Password or PIN — something the user knows
• Registered phone or authenticator device, security key, or smart card — something the user has
• Client certificate with its private key — commonly used for machine-to-machine authentication such as mutual TLS (mTLS)
• Client secret — a confidential credential used by some OAuth clients. The client ID identifies the client, while the client secret must be kept confidential.

In OAuth, a client is an application or service requesting access — not the human user or their computer.

Multi-factor authentication (MFA) combines authenticators from more than one factor category — for example, a password plus a registered security key.

Once authentication succeeds, a system may create a login session or issue credentials or tokens that allow subsequent requests to be associated with that authenticated account.

Authentication itself does not decide which files, APIs, or admin pages the account may access.

Showing an ID badge at a controlled entrance is a useful analogy for authentication: you provide evidence for the identity you claim. Whether that badge lets you enter a server room is a separate authorization decision.

Authorization: Deciding What You Can Do

Authorization evaluates whether an authenticated identity may perform a requested action on a requested resource.

Authorization often uses:

• Roles — named labels such as developer, billing-admin, or viewer
• Permissions — specific actions such as reading a report or deleting a user
• OAuth scopes — labels such as reports:read that describe the type of access an application requests or has been granted
• Policy rules — contextual decisions based on attributes such as department, resource owner, or time of day

Role-based access control (RBAC) maps identities to roles and roles to permissions. Attribute-based access control (ABAC) makes authorization decisions from attributes of the subject, resource, requested action, and environment.

Successful authentication does not imply full access. Priya may sign in correctly and still be denied one admin API because her role allows read but not delete.

Applications, API gateways, and authorization services enforce these checks. Keycloak can include roles, scopes, and other claims in access tokens, but something in the request path still decides whether the operation is allowed. See Keycloak realm roles vs client roles for how role claims reach tokens.

Authentication vs Authorization: Key Differences

Passwords, client secrets, and certificates are used for authentication. Role assignments, permissions, and scope checks are authorization. A password proves control of an account; it does not by itself grant admin rights.

The user does not necessarily re-enter credentials for every request. A session cookie, bearer token, client certificate, or other previously established credential may identify or authenticate the request.

How They Work Together in a Login and API Request

A typical web plus API flow separates the two steps clearly.

Browser login

1. Priya enters username and password — identification and authentication start.
2. The IAM server verifies her password and any required additional factor. If authentication succeeds, it creates a login session.
3. The application reads her roles or other access information and checks whether she may open a protected page or perform an action. It may also hide UI options she cannot use, but the server must still enforce access when the request arrives.

API call with a bearer token

1. Priya's client sends an access token in the Authorization header.
2. The API validates the access token — for example, checking its signature and claims when the token is a JWT, or using another validation mechanism appropriate to that token type.
3. If the token is valid, the API evaluates its scopes, roles, other claims, and request context to decide whether the requested operation is allowed.

For a JWT access token, validation commonly includes verifying its signature and checking claims such as issuer, audience, and expiration. Some access tokens are opaque tokens, meaning the API cannot decode useful claims from the token itself. The API cannot validate an opaque token by decoding it like a JWT; it typically checks the token using a mechanism provided by the authorization server.

A valid bearer access token proves that the caller possesses that token, but it does not necessarily prove the identity of a particular human user. An OAuth access token's main purpose is to grant access to a protected API. For example, a machine using the Client Credentials grant can have an access token even though no person signed in.

Use an access token when calling protected APIs. An OpenID Connect ID token describes who signed in; it is not the token you send to routine resource APIs.

GET /api/reports/finance HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6...

Once the API accepts the token, it still has to decide whether that token permits this particular operation. The API may also obtain information about Priya from token claims, depending on how the authorization server issued the token. If her role includes reports:read but not the permission required to delete reports, a DELETE on the same resource can still return 403 Forbidden even when the token is valid.

Common Methods and Protocols

The same distinction appears in browser logins, APIs, and machine-to-machine access.

Authentication methods

• Password and MFA at a login page
• TLS client certificates for service APIs
• Machine or client authentication — for example, a client secret or client certificate

Authorization models

• RBAC with application or realm roles
• Scope-based access on OAuth access tokens
• ABAC with policy engines or custom application logic

OAuth and OpenID Connect are often confused here. OAuth 2.0 is primarily an authorization framework for obtaining access to protected resources. Many OAuth flows involve delegated access on behalf of a user, while flows such as Client Credentials let a machine client request access for itself. OpenID Connect adds a standardized authentication layer on top of OAuth 2.0 for user sign-in.

Keycloak can act as an OpenID Connect identity provider and OAuth authorization server. It authenticates users for OIDC login and issues access tokens that APIs can use when making authorization decisions. Keycloak clients explained covers how applications register as OIDC clients or SAML service providers.

Authentication and Authorization Examples

Non-human clients authenticate with credentials or certificates, then authorization still limits which endpoints they may call.

401 vs 403: Where the Difference Appears

Many HTTP APIs use status codes to signal which step failed:

Despite its name, HTTP 401 Unauthorized is normally associated with authentication, while 403 Forbidden is commonly used for an authenticated caller who lacks sufficient access. APIs may deliberately return 404 Not Found instead of 403 when revealing that a resource exists would disclose information.

Example — missing or invalid token:

GET /api/reports/finance HTTP/1.1
Host: api.example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer

Example — valid token, insufficient permission:

DELETE /api/reports/finance/annual HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6...

HTTP/1.1 403 Forbidden

Summary

Authentication verifies that a user or system can prove control of the account it claims to be using. Authorization decides what that authenticated user or system is allowed to do. Authentication and authorization often work together: first the system verifies the account or caller, then protected resources evaluate whether that caller has sufficient access.

OAuth 2.0 is primarily an authorization framework for obtaining access to protected resources; OpenID Connect adds standardized user sign-in on top. In OAuth-protected API calls, the resource server first validates the access token and then determines whether the token grants sufficient access for the requested operation. When debugging, 401 usually points to missing or invalid credentials, while 403 often means the caller is known but not allowed for that operation.

References

• NIST SP 800-63 Digital Identity Guidelines — authentication and authenticator terminology
• NIST Computer Security Resource Center — Access Control — authorization definitions
• OAuth 2.0 Authorization Framework (RFC 6749) — authorization framework scope
• The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) — bearer token presentation to resource servers
• HTTP Semantics (RFC 9110) — 401 Unauthorized and 403 Forbidden definitions
• OpenID Connect Core 1.0 — authentication layer on OAuth
• Keycloak documentation — upstream IAM server referenced in this course