What Is the Difference Between Authentication and Authorization?
From the earlier reference collection. Read the current software blog.
Authentication establishes which identity is making a request; authorization decides whether that identity may perform the requested action on a resource.
Authentication answers who
Authentication is the process of establishing an identity for a request. A user may sign in with a password and an additional factor, or a service may present a credential issued for machine-to-machine use. The application checks that evidence according to its design and associates the request with an identity or account.
Authentication does not automatically grant access to every part of an application. A valid login tells the system which principal is acting; it does not establish that the principal owns a particular record or may change a particular setting.
Authorization answers what is allowed
Authorization evaluates whether an identified principal can perform a specific action on a specific resource under the applicable rules. Those rules might depend on role, ownership, organization membership, or a narrow permission granted for one task.
For example, authentication may identify a signed-in user as user-42. Authorization then checks whether that user may edit document doc-9. A successful identity check paired with a failed permission check should deny the edit while leaving the account authenticated.
Keep the checks distinct
Combining the concepts can create dangerous assumptions. A route that checks only whether a session exists may allow any signed-in user to access another person’s data. Conversely, an authorization rule cannot reliably decide access if the request’s identity has not been established or has expired.
Apply permission checks close to the resource or operation being protected, and make sure they cover every path to that operation, including background jobs and APIs. Avoid relying only on hiding a button in the interface; a client can be modified or a request can be sent directly.
Make access decisions reviewable
Use clear permission rules and test both allowed and denied cases. For a document editor, tests might cover its owner, a collaborator with edit access, a reader, and an unrelated account. Include checks for resource identifiers supplied by the caller, since changing an identifier should not bypass ownership rules.
The distinction also improves troubleshooting. If a login fails, investigate authentication evidence and account state. If a signed-in person is refused an action, investigate the authorization rule for that resource and operation. Systems often need both layers, and secure handling depends on keeping their responsibilities explicit.