Authentication proves who you are. Authorization controls what you can do. Learn the 5 key differences, why conflating them breaks security, and how to implement each.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
Authorization vs authentication are two terms used interchangeably in most documentation, codebases, and stand-up meetings, but they're different systems with different inputs, outputs, and failure modes. The vocabulary slip is harmless in conversation. In code, it's the leading cause of broken access control vulnerabilities (OWASP A01), the most common web application weakness for years running.
Authentication is the process of verifying that a user, service, or device is who or what it claims to be. Authorization is the process of determining whether a verified identity is permitted to perform a specific action or access a specific resource. The output of the first becomes the input to the second.
Authentication answers "who are you?" The system validates credentials (a password, a passkey, a certificate, a one-time code), issues a session or token, and produces a verified identity downstream systems can trust. The method changes. The purpose does not.
Authorization answers "what are you allowed to do?" It takes the verified identity that authentication produced and evaluates it against a set of policies to produce a binary decision: permit or deny. Authorization runs against a policy. Authentication runs against a credential store.
The token, session, or assertion produced by authentication is the only thing authorization knows about the user. If authentication fails, authorization never runs. If authorization is missing, authentication on its own gives every logged-in user the same level of access, which is rarely what you want.
Authentication and authorization differ across five dimensions: their purpose, their position in the request lifecycle, what they consume as inputs, what they produce as outputs, and how each fails when the two concerns are not properly separated.
Authentication produces a verified identity. Authorization produces an access decision. Different goals, different systems, different error states. A failed authentication returns 401 Unauthorized. A failed authorization returns 403 Forbidden. The HTTP status codes encode the distinction long before any framework imposes its own opinion.
Authentication runs first and is a prerequisite for authorization. You cannot enforce access policies for an identity that has not yet been established. Authentication gates the entrance. Authorization governs what the authenticated party can do once they're inside.
Authentication consumes credentials: passwords, biometric data, tokens, certificates. Authorization consumes identity claims: user ID, role, group membership, attributes about the requester or the resource. The two systems require fundamentally different data to do their jobs, which is one reason they're cleanest when they live in different services.
Authentication produces a session, a JWT, an opaque token, or a certificate encoding the verified identity. Authorization produces a permit-or-deny decision, sometimes with scope or conditions attached. The output of authentication is the input to authorization. That handoff is the single most important interface in your auth stack.
When permission checks get embedded inside authentication middleware, the system fails to enforce least privilege correctly. A typical pattern: a developer adds a "logged in?" check to a sensitive API endpoint but omits the role check. Every authenticated user inherits admin-level access. This pattern, repeated across a codebase, is the root cause of OWASP A01 (Broken Access Control). One misconfigured route is all it takes.
| Dimension | Authentication | Authorization |
|---|---|---|
| Purpose | Verify identity: confirm who the user is | Enforce policy: determine what the user can do |
| Position | Always runs first | Runs after authentication succeeds |
| Input | Credentials (password, token, biometric) | Identity claims (user ID, role, attributes) |
| Output | Session or token encoding verified identity | Access decision: permit or deny |
| Failure mode | 401 Unauthorized: identity not verified | 403 Forbidden: access denied by policy |
| Common mistake | Using it to also check permissions | Skipping it entirely for authenticated users |
Authorization can technically operate without user authentication in limited scenarios, such as policies applied to public resources based on request attributes like IP address or time of day. In almost every real-world system involving user identity, authentication must precede authorization.
A rate-limiting policy that denies requests from a specific IP regardless of who is making them is a form of authorization without authentication. The system is making an access decision based on a request attribute. But this isn't "authorization" in the IAM sense. In any system where the access decision depends on who the user is, authentication is always required first.
Authorization policies evaluate identity claims. If no identity has been established, there are no claims to evaluate. You cannot grant or deny a resource to "no one." The sequencing is not a convention. It is an architectural dependency baked into how every modern auth standard is written.
Authentication methods are the mechanisms by which a user or system proves its identity. The most common in production today are password-based credentials, multi-factor authentication, passkeys and biometrics, SSO via SAML or OIDC, and certificate-based authentication for machine identities.
Passwords remain the most widely deployed authentication mechanism, but they're also the most attacked. MFA adds a second verification factor (TOTP, push notification, hardware key) that drops credential-compromise risk substantially. Worth noting: NIST 800-63B now recommends against knowledge-based security questions and length-only password requirements, both of which still show up in real production systems more often than they should.
Passkeys use public-key cryptography (FIDO2/WebAuthn) and bind authentication to a device or biometric. They're phishing-resistant by design because there's no shared secret to intercept. The industry shift toward passwordless isn't a fad. It's a direct response to credential theft being the single most common attack vector for years running.
SSO lets a user authenticate once against an identity provider and access multiple applications without re-entering credentials. SAML covers the enterprise side. OIDC covers the modern cloud side. Certificate-based authentication is what you reach for in machine-to-machine and service account scenarios where no human is present.
For engineering teams that need a production-ready open source authentication layer (registration, login, MFA, passkeys, social login, and session management) without building the flows from scratch or depending on proprietary SaaS, Ory Kratos is a headless, API-first identity management system designed to run on your own infrastructure at any scale.
Explore Ory Kratos for authentication
Authorization policies can be expressed through three main models: Role-Based Access Control (RBAC), which grants permissions based on role assignments; Attribute-Based Access Control (ABAC), which evaluates dynamic attributes; and Relationship-Based Access Control (ReBAC), which defines permissions through entity relationships.
RBAC assigns users to roles and attaches permissions to those roles. Simple, auditable, supported natively by most IAM tools. It's the right default for organizations with stable, well-defined role hierarchies. The model breaks down when the number of roles proliferates to cover every edge case, which is the failure mode known as role explosion.
ABAC evaluates attributes of the user, the resource, the action, and the environment to make dynamic access decisions. More flexible than RBAC and higher implementation overhead. The right choice for regulated industries where access has to adapt to context: time, location, resource sensitivity, compliance requirements that can't be expressed with static roles.
ReBAC grants access based on relationships between entities: "user is editor of this document," "user is member of this team." The model behind Google Drive, GitHub, and Ory Keto. The right choice for collaborative, resource-sharing systems where permissions inherit through hierarchies.
For teams that need to enforce fine-grained access policies at the authorization layer (determining what each authenticated user is permitted to do across resources, roles, and relationships) Ory Keto is an authorization server built on Google's Zanzibar model, optimized for low-latency permission checks at production scale.
Explore Ory Keto for authentication
In a production system, authentication and authorization form a two-step access control sequence: authentication runs first to verify the requester's identity and issue a token, then authorization evaluates the token's claims against an access policy to permit or deny the specific action requested.
Each step is a separate concern. Each step can be implemented, scaled, and audited independently. That separation is what makes auth stacks recover gracefully when one component fails or needs to be replaced.
The token or session produced by authentication is the trust boundary. Everything downstream of authentication must treat the token as untrusted input until authorization validates the specific permissions encoded in it. This is why placing permission checks inside the authentication layer is dangerous: it collapses two separate trust evaluations into one step that can be bypassed by a single misconfigured route, middleware, or claim.
Open source authentication and authorization tools are purpose-built systems that implement one side of the security stack: identity management and login flows on the authentication side, and permission policy evaluation on the authorization side. Using dedicated tools for each concern is architecturally cleaner than combining both in a single system.
A monolithic platform that handles both authentication and authorization in one system creates coupling between two concerns with different scaling, latency, and policy change characteristics. Authentication events are infrequent (login happens once per session). Authorization checks happen at every request, sometimes thousands per second. Separating them lets each system be optimized independently. That's the practical reason the industry has moved toward dedicated tools over monolithic platforms.
Open source authentication options range from headless identity management systems (Ory Kratos, Keycloak) to self-hosted OIDC providers and SSO solutions. The key evaluation criteria: API-first design, support for modern auth methods (passkeys, TOTP, social login), and the ability to run on your own infrastructure without per-MAU pricing.
Open source authorization options range from policy engines (OPA, Casbin) to relationship-based permission servers (Ory Keto, SpiceDB). Key evaluation criteria: latency at scale, support for your required access model (RBAC, ABAC, ReBAC), and clean separation from identity management.
The decision to build, self-host open source, or use managed authentication and authorization infrastructure depends on three factors: whether your compliance posture requires data sovereignty and infrastructure control, whether your team has the capacity to maintain auth infrastructure long-term, and whether your access control requirements exceed what off-the-shelf SaaS can configure.
Open source tools like Ory Kratos and Ory Keto give engineering teams production-grade authentication and authorization infrastructure they can audit, extend, and run on their own infrastructure, without the vendor lock-in or per-MAU pricing that makes SaaS platforms expensive at scale. The companies that move to open source identity tend to share a profile: they hit a scaling, customization, or compliance ceiling on a SaaS platform and need to bring the auth layer back under their control.
For a deeper walkthrough on combining both concerns in a single application, our guide to building auth with Ory Kratos and Keto shows the integration end-to-end. For teams thinking about access models more broadly, the broader customer identity and access management hub covers how authentication and authorization fit into a complete identity stack.
Ory offers open-source solutions above as well as commercial offerings that bring more enterprise-level features, support, 24/7 SLAs, and more. Ory offers those commercial solutions as a SaaS or self-hosted options. Compare the varying options Ory offers.
Compare Ory Kratos + Keto deployment options
The takeaway: authentication and authorization aren't two names for the same thing. They're two systems with different jobs. Treating them that way at the architecture level prevents the most common security vulnerabilities, scales cleanly as your product grows, and gives you the option to swap implementations later without rewriting everything. The teams that get this distinction right in the first six months of a new product rarely have to revisit it. The teams that don't end up rebuilding their auth layer twice.
