Authentication vs. authorization: identity is not permission

Authentication verifies a claimed identity; authorization determines whether a requester may perform a particular action on a resource. A successful sign-in does not, by itself, establish permission to edit a document. OWASP distinguishes identity verification from approval of a requested action and warns that authenticated users are not necessarily allowed to access every resource. (Authentication definition, authorization definition)

Authentication establishes identity; authorization evaluates access

The distinction becomes clearer when you write the questions an application must answer:

• Authentication: Is this requester the user or entity they claim to be?
• Authorization: May this requester perform this action on this resource?

For a document editor, “this request belongs to Alice” and “Alice may edit document 42” are separate conclusions. The first identifies the requester. The second requires a permission rule that applies to Alice, editing, and document 42.

Authorization does not always require authentication. A policy can allow anonymous visitors to read public content. OWASP gives public images and login pages as examples of resources that may be accessible without authentication. The relevant distinction is identity versus permission—not simply whether a request happens before or after login. (OWASP Authorization Cheat Sheet)

Login and sessions do not replace permission checks

Successful login establishes an authenticated identity. Session management lets a server maintain state across subsequent interactions, including a user’s signed-in state. OWASP defines session management in terms of maintaining interaction state, not granting resource permissions. (OWASP Authentication Cheat Sheet)

That state is useful input to an access decision, but it is not a universal permission grant. In a private document-sharing application, a session identifying Alice still leaves an unanswered question: what relationship does Alice have to the requested document?

Keep those responsibilities explicit in the design. A check named is_signed_in should not stand in for one named can_edit_document. The latter needs an action-specific rule, not just evidence of an authenticated account. This follows OWASP’s distinction between authenticated users and the actions they are privileged to perform. (OWASP Authorization Cheat Sheet)

A document-sharing policy makes the difference concrete

Consider a private document with two relationships: editors and viewers. Define the entire policy for this example as follows:

• Editors may write.
• Editors and viewers may read.
• A user with neither relationship receives neither permission.

This matches the example in Ory Keto’s documentation: write checks membership in the document’s editors, and read allows either write permission or membership in its viewers. (Ory Keto permission example)

For that policy, the decisions are:

Relationship to the document	Read	Write
Editor	Allow	Allow
Viewer only	Allow	Deny
Neither	Deny	Deny

Suppose Alice is a viewer, but not an editor, of document 42. Her login can succeed while an attempt to edit that document is denied. If Bob is an editor of document 42, both reading and writing are permitted. Bob’s relationship to document 42 says nothing by itself about document 99.

The important engineering detail is that the decision concerns a subject, action, and resource. “Authenticated user” is not sufficiently specific to express this policy.

Make the fallback explicit: if no rule grants the requested action, deny it. This follows OWASP’s recommendation to configure authorization to deny access by default rather than rely on assumptions about framework or library defaults. (OWASP Authorization Cheat Sheet)

OAuth 2.0 access is different from OpenID Connect sign-in

Protocol names can blur the distinction unless their purposes stay explicit.

OAuth 2.0 is an authorization framework. RFC 6749 describes it as enabling a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner or on the application’s own behalf. Delegation is therefore an important OAuth use case, but not every OAuth interaction represents a human signing in. (RFC 6749)

OpenID Connect adds an identity layer on top of OAuth 2.0. It enables a client to verify an end user’s identity based on authentication performed by an authorization server and to obtain basic profile information. That is the sign-in concern; OAuth 2.0 alone should not be used as a synonym for user authentication. (OpenID Connect Core)

In the document-sharing example, keep three questions separate:

1. Who is the user signing in? That is the identity question addressed by OpenID Connect.
2. What limited access has a client application obtained? That is an OAuth authorization question.
3. May the relevant subject edit document 42? That is the application’s resource-permission question.

For this application, define the editor and viewer rules explicitly rather than treating the presence of an OAuth integration as the document policy. Those rules need a representation and a point at which the application enforces the decision.

Ory’s components illustrate the responsibility boundaries

Ory’s documentation describes a concrete separation of responsibilities within Ory Network:

Component	Documented role in Ory Network
Ory Kratos	API-first identity and user management, including registration, login, recovery, and account management.
Ory Hydra	OAuth 2.0 and OpenID Connect. Ory describes the Network service as a headless API that can work with an existing user management system.
Ory Keto	Fine-grained permissions based on subject-resource relationships, with permission inheritance through groups, roles, and hierarchies.

Use this separation as an architectural model, not a requirement to deploy three products. Identity management, protocol-level access, and application permissions are separate design responsibilities; they do not necessarily require separate services.

Test identity and permissions independently

Turn the document policy into tests that check whether login success is being mistaken for access approval:

• An authenticated viewer who is not an editor can read the document but cannot write it.
• An editor can write the document for which they have the editor relationship.
• That same editor cannot write a different document where they have neither relationship.
• An authenticated user with neither relationship cannot read the private document.

These are expected results derived from the editor/viewer policy, not results of a test run. (Policy example)

For the private-document handler, make both decisions visible: establish the requester’s identity, then evaluate the requested action against the requested document. Perform the operation only when the policy permits it. The central rule is simple: knowing who made a request is not the same as deciding that the request is allowed.