Authentication, authorization, tokens, and OAuth

In Module 4, you encountered this HTTP header: Authorization: Bearer x81k…

That header carries information the server can use when deciding whether a request should be allowed.

Before a protected system performs an action, it commonly needs to answer two separate questions: who or what is making this request? And: is that requester allowed to perform this action?

These questions are called authentication and authorization.

They sound similar, but the distinction between them is foundational.

What is authentication?

AuthenticationConcept · lights on your mapauthenticationVerifying who or what is making a request: “who are you?” Engineers shorten it to authn. A separate question from authorization, with separate failures. is the process of verifying an identity.

It answers: who are you?

When a person signs in using an email address and password, the application checks whether the provided credentials match a real account.

Other authentication methods include:

• A password
• A one-time code
• A fingerprint or face scan
• A security key
• A saved login session
• A token
• An API key used by software

Authentication does not necessarily mean proving the identity of a human. Software systems also authenticate themselves when communicating with other systems.

The result is that the server has evidence about who or what is making the request.

What is authorization?

AuthorizationConcept · lights on your mapauthorizationDetermining what an already-identified requester is allowed to do: “what are you permitted to do?” Engineers shorten it to authz. A separate question from authentication, and answered after it. determines what an authenticated identity is allowed to access or do.

It answers: what are you permitted to do?

A company employee may successfully sign in to an internal tool, which means the employee has been authenticated.

However, the employee may not have permission to view payroll records or issue large refunds, and preventing that access is an authorization decision.

A customer may be allowed to view their own order but not another customer’s order, and an administrator may be allowed to delete an account, while an ordinary user is not.

Authentication establishes identity. Authorization applies permissions to that identity.

Seeing the difference

Consider several outcomes.

A user enters the wrong password, so the application cannot verify the identity. That is an authentication failure.

A user signs in successfully but attempts to open an administrator page without the required permission. Authentication succeeded, but authorization denied the action.

A support agent is allowed to view an order but cannot issue a refund above $500 without a manager’s approval. The agent is authenticated, and authorization permits some actions but not others.

A useful way to remember the pair is: authentication asks who you are. Authorization asks what you may do.

Engineers sometimes shorten the words to authn and authz because their spellings are so similar.

Authentication and HTTP status codes

The status codes from Module 4 often reflect this distinction.

A server may return: 401 Unauthorized

Despite its confusing name, 401 generally means that valid authentication is missing or has failed, so the client may need to log in, provide a token, or replace an expired credential.

A server may instead return: 403 Forbidden

This generally means that the server understands who is making the request but refuses to allow the requested action.

A useful beginner distinction is:

• 401: You have not successfully proven who you are.
• 403: Your identity does not have permission to do this.

Real systems can use these codes in slightly different ways, but this is the common interpretation.

Not every request requires authentication

Some information is intentionally public.

A coffee company may allow anyone to retrieve its public menu: GET /menu

The server may not need to know who is asking.

However, placing an order, viewing purchase history, or changing an account requires the server to connect the request to an identity.

Protected endpoints commonly require authentication and authorization. Public endpoints may not.

From login to later requests

A user should not need to enter a password before every request.

Instead, the user typically proves their identity once during loginConcept · lights on your maploginThe moment a user proves their identity (with a password, code, or biometric check) and receives something the client can present with later requests: a session identifier or a token. Continuity, so identity isn’t re-proven per request.. The application then gives the client something it can present with later requests.

In Module 5, you learned one version of this pattern:

1. The user logs in.
2. The server creates a session.
3. The browser receives a cookie containing a session identifier.
4. Later requests include the cookie.
5. The server connects the identifier to the user’s session.

Tokens provide another common way to carry authentication information between requests.

What is a token?

A tokenConcept · lights on your maptokenA value a client presents as evidence that it has been granted particular access. It can represent a user, a session, an application, permissions, or a limited period. The server validates it before relying on what it represents; carried in the Authorization header of protected requests. is a value that a client presents as evidence that it has been granted particular access.

After a user logs in, the authentication system may issue a token. Then the client stores it temporarily and includes it with protected API requests.

A request might contain: Authorization: Bearer eyJhbGc…

Bearer means that possession of the token is enough to present it. The server must therefore protect and validate the token carefully.

The token may represent:

• A particular user
• A logged-in session
• An application
• A set of permissions
• A limited period of access

Some tokens contain readable claims protected by a digital signature, while others are opaque strings whose meaning is stored only on the server.

The important idea is not what the characters look like but that the server validates the token before relying on what it represents.

What does the backend check?

When the backend receives a token, it may check:

• Was the token issued by a trusted system?
• Has it expired?
• Has it been altered?
• Is it intended for this application?
• Has it been revoked?
• Which identity does it represent?
• Which permissions or scope does it carry?

If the token passes the authentication checks, the backend can determine the requester’s identity.

It must then perform authorization: is this identity allowed to access this particular order or perform this action?

A valid token does not automatically grant unlimited access.

Reading an authenticated API request

Consider this request:

You can now read the full message. The backend may then:

1. Validate the token.
2. Identify the requester.
3. Check whether that requester is allowed to place an order.
4. Validate the JSON payload.
5. Apply business logic.
6. Save the order.
7. Return a response.

Authentication and payload validation are separate steps. A request can come from a valid user while still containing invalid order information.

What is an API key?

An API keyConcept · lights on your mapAPI keyA secret value commonly used to identify and authenticate an application, project, or account making API requests. It often identifies the software rather than an individual person. Used for access decisions, usage counting, rate limits, and billing; must be protected like a password. is a secret value commonly used to identify and authenticate an application, project, or account making API requests.

Suppose the coffee company uses a third-party mapping service, and its backend may include an API key with requests so the provider can identify the coffee company’s account.

The provider may use that identity to:

• Decide whether the request is allowed
• Count usage
• Apply rate limits
• Determine billing
• Identify which features are available
• Investigate misuse

Unlike a user login, an API key often identifies the software project rather than the individual person currently using the product.

The exact capabilities vary by provider. Some API keys identify a project but require additional credentials for sensitive actions.

Why API keys must be protected

An API key is a secret.

If someone steals it, they may be able to send requests that appear to come from the legitimate application, which could create unauthorized charges, expose information, consume usage limits, or damage the company’s reputation.

API keys should generally not be placed directly into frontend code because users can inspect code running on their own devices.

Instead, sensitive keys are commonly stored in protected backend environments and retrieved through systems designed to manage secrets.

You will study secrets management later in the curriculum.

The important principle is: a secret placed in client-side code should be assumed visible to the user.

Humans and machines authenticate differently

Humans commonly authenticate through interactive methods such as passwords, one-time codes, or biometric checks, but software systems cannot usually stop and type a password into a login screen each time they communicate.

Instead, machine-to-machine communication may use:

• API keys
• Access tokens
• Certificates
• Signed requests
• Special machine identities called service accounts

These approaches allow one system to prove its identity to another without a person participating in each request.

What is OAuth?

OAuthConcept · lights on your mapOAuthA widely used standard for allowing one application to access another service on someone’s behalf without receiving that person’s password. You authenticate with the provider directly; the provider hands the application a token representing the granted access: limited by scopes, expirable, revocable. is a widely used standard for allowing one application to access another service on someone’s behalf without receiving that person’s password.

Imagine that the coffee app wants permission to read basic information from your Google account.

The coffee app should not ask you to type your Google password directly into its own form. That would require you to trust the coffee company with credentials that could access your Google account.

Instead, the coffee app redirects you to Google.

You authenticate directly with Google. Google then asks whether you want to grant the coffee app particular access.

If you approve, Google gives the coffee app a token representing that permission, and the coffee app receives delegated access without ever seeing your Google password.

“Log in with Google”

The button commonly labeled Log in with Google uses OAuth-related technology, but authentication introduces an additional detail because OAuth was primarily designed for delegated authorization: allow this application to access a particular capability on my behalf.

For login and identity, systems commonly use OpenID Connect, an identity layer built on top of OAuth.

OpenID Connect allows Google to provide verifiable information about the signed-in user, while OAuth manages the access-granting flow around it.

You do not need to remember the protocol distinction deeply yet. A useful beginner model is: “Log in with Google” lets Google verify your identity so the other application does not need to handle your Google password.

The coffee app still creates and manages its own account and permissions after receiving that identity information.

OAuth does not grant unlimited access

OAuth access can be limited through permissions commonly called scopes.

An application might request permission to:

• View basic profile information
• Read calendar events
• Create calendar events
• Access files
• Send email

The user may grant only the access requested and approved.

A token can also expire, be revoked, or be limited to a particular application.

This is authorization in action. Beyond identifying the application, the token describes which capabilities have been delegated.

Sessions, tokens, and API keys

These concepts overlap, but they commonly serve different purposes.

A session is remembered information connecting a series of interactions to a user.

A cookie is often the browser mechanism carrying a session identifier or token.

A token is a value presented as evidence of identity or granted access.

An API key commonly identifies an application, project, or provider account.

OAuth is a process for granting one application limited access to another service without sharing the user’s password.

The exact implementation differs between systems. The most important skill is recognizing the purpose each mechanism serves.

The mental model to remember

Authentication verifies who or what is making a request.

Authorization determines what that identity is allowed to do.

A token is a value a client presents as evidence of granted access.

An API key commonly identifies and authenticates an application or project using an external API.

OAuth allows one application to receive limited access to another service without receiving the user’s password.

OpenID Connect commonly adds identity to OAuth-based login experiences such as “Log in with Google.”

You should now be able to examine a protected API request and identify how the server learns who is asking, checks what they may do, and then validates the requested action.