Glossary
Token-based authorization is a method of conveying a user’s authenticated identity and permissions between systems using signed tokens (most commonly JSON Web Tokens (JWTs)) so that services can verify access rights without re-authenticating the user on every request. It’s the mechanism underpinning modern web, mobile, and API authorization, including OAuth 2.0 and OpenID Connect flows.
Rather than a service repeatedly checking credentials, the user authenticates once and receives a token that encodes their identity and permissions; each subsequent request presents the token, and the service verifies it. This makes authorization stateless and scalable across distributed systems and APIs.
After authentication, an authorization server issues a token (typically a JWT) containing claims about the user (identity, roles, scopes, permissions) and a cryptographic signature. The client includes this token with each request (commonly in an HTTP header). The receiving service validates the signature (proving the token is authentic and unaltered) and reads the claims to make an authorization decision, without calling back to the auth server for every request. Tokens are time-limited and often paired with refresh tokens to obtain new ones.
A JWT has three parts: a header (token type and signing algorithm), a payload (the claims: who the user is, what they can do, expiry), and a signature (which verifies integrity and authenticity). Because it’s signed, a service can trust a JWT’s contents without a database lookup: but because the payload is only encoded, not encrypted, JWTs shouldn’t carry secrets, and validation must always check the signature and expiry.
Token-based authorization is powerful but must be handled carefully. Tokens should be short-lived to limit the damage if stolen, transmitted only over encrypted connections, and stored securely on the client. A major risk is token theft: a stolen token can be replayed to impersonate the user (see session hijacking), which is why continuous evaluation, token binding to a device, and sensible expiry matter. Services must always validate the signature and claims, never trust an unverified token, and check scopes to enforce least privilege rather than assuming a valid token means "allow everything."
Token-based authorization is the backbone of OAuth 2.0 (delegated authorization) and OpenID Connect (identity), and of API and microservice security generally. It enables single sign-on, delegated access ("allow this app to access my calendar"), and stateless authorization at scale. Understanding tokens is essential for developers building modern authenticated, authorized applications: and for securing them, since so much access hinges on how tokens are issued, scoped, validated, and protected.
What is token-based authorization?
Using signed tokens (like JWTs) to convey a user’s identity and permissions between systems, so services authorize requests without re-authenticating each time.
What is a JWT?
A JSON Web Token: a signed token with a header, a payload of claims (identity, permissions, expiry), and a signature verifying its integrity.
Are JWTs encrypted?
By default the payload is encoded, not encrypted, so JWTs shouldn’t carry secrets; security relies on the signature, HTTPS, and short expiry.
What’s the main risk with tokens?
Token theft (a stolen token can impersonate the user) which is why short expiry, encryption, token binding, and continuous evaluation matter.
Related: OAuth 2.0 · OpenID Connect (OIDC) · Authorization · Session Hijacking · API Security · Fine-Grained Authorization (FGA)
