Authentication Establishes an Account; Authorization Governs Its Actions

Authentication and authorization are related, but a successful sign-in does not answer every access question. Authentication establishes something about the account or entity making a request. Authorization determines whether that entity may perform a particular action on a particular resource.

A user can therefore be correctly signed in and still be unable to open a document. That can be the intended result: the system recognizes the account, but the document has not been shared with it. Resetting the password would not address that missing permission.

State what is being authenticated

In an ordinary account login, authentication commonly checks evidence that the user controls an authenticator associated with the account. The evidence might involve a password, a security key, or another supported method. The specific design determines what assurance is obtained.

NIST's authentication glossary includes definitions covering people, processes, devices, and account authenticators. These are context-specific definitions. Authentication does not always mean that a person's legal identity has been investigated or that the account's display name has been independently verified.

For example, signing in successfully to an account called GardenPlanner does not by itself prove the civil identity of the person holding it. It establishes the result of that service's authentication process. Additional identity proofing, where used, is a separate process with its own evidence.

The same care applies to servers. Our HTTPS explanation distinguishes a protected, authenticated connection to a domain from an endorsement of the business operating there. The word authentic should always be attached to the thing actually checked.

Authorization has a subject, action, and resource

An access decision can be expressed as: may this account perform this action on this object in these circumstances? Changing any part of that sentence can change the answer.

The subject might be a person using an account or a program acting through its own service identity. The action might be reading, editing, deleting, exporting, or changing permissions. The resource might be one file, a folder, an account setting, or an administrative function.

NIST's authorization definitions describe privileges and decisions permitting or denying access. The glossary also contains other uses, such as authorization to operate a system. Those should not be confused with the everyday application permission discussed here.

“Has access” is consequently an incomplete description. An account may be able to view a document without editing it, edit it without sharing it, or administer a workspace without being the author of every file. The exact permission model belongs to the service.

A document example

Imagine a fictional project service with three accounts and one budget document. The project owner can read, edit, and share it. A reviewer can read and comment. Another valid account has no permission to open it.

All three accounts can pass the login process. Their different results are caused by authorization in this example, not by one account having a more correct password. The table describes an invented policy, not the universal meaning of owner or reviewer in every product.

Now suppose the reviewer leaves the project and the owner removes that permission. The reviewer may still be signed in to the service while losing access to the document. Account authentication and document membership have changed independently.

A permission can be inherited or contextual

Some systems grant access through membership in a group, role, or parent folder. Others attach permissions directly to an individual resource. A user may therefore receive access without appearing as a separately named entry in every document's sharing panel.

This is a reason to inspect the actual permission path, not to assume that an apparently missing entry proves no access exists. Conversely, belonging to an organization does not universally grant access to every object it owns.

Policies can also consider circumstances such as the requested action, device state, or administrative restrictions. A successful login from one context does not guarantee the same action is allowed from every other context. Product documentation identifies which conditions the service actually uses.

Our private and public IP address guide addresses another boundary: network addressing is not equivalent to account permission. A resource being reachable across a network does not establish that the request is authorized to read it.

Local device permission is another boundary

A computer application may need permission from the operating system to use a microphone, camera, or location service. It may separately need an authenticated account for an online feature. Granting one does not necessarily grant the other.

For instance, a meeting application could recognize the user's account but lack operating-system permission to use the microphone. Or it could have microphone permission while the user is not allowed to enter a particular meeting. These are different conditions despite appearing in the same application.

The firmware, operating-system, and application guide helps locate those layers. A permission dialog belongs to a specific component and resource; its presence should not be interpreted as a universal approval for the application to do anything.

A continuing session is not a fresh password check

After authentication, a service commonly uses a session mechanism so the person does not repeat the full login process for every page. The details differ, but a familiar account avatar can reflect a continuing session rather than a new identity check at that moment.

The cookies and cache explanation distinguishes session-related state from stored page resources. Clearing a cache and changing account authorization are different actions, even if a troubleshooting screen places them near one another.

A session may end because the user signs out, the service expires it, or another policy takes effect. Permissions can also change while a session exists. Therefore, being signed in earlier in the day does not prove that a later request has the same authorization result.

Describe an access failure without guessing

A precise support report records which account is active, what resource was requested, what action failed, and what message appeared. Include the expected permission and how it was granted. Avoid sending passwords or secret tokens as evidence.

“I can sign in, but this account receives access denied when opening the shared folder” is more informative than “my password is broken.” It narrows the observable failure without claiming that the cause is already known.

A hidden button is also different from a permitted action. The user interface may omit an action for many reasons, and a secure system must enforce the relevant permissions where requests are processed. The visual presence of a button is not proof that the server will approve the operation.

What a stronger sign-in does and does not change

Improving authentication can reduce the risk that an unauthorized person takes over an account. It does not automatically correct overly broad permissions already assigned to that account. If an account can delete every project, stronger sign-in still leaves it with that authority when properly authenticated.

Similarly, restricting permissions does not prove that the account is controlled by its intended user. Authentication and authorization support different parts of access control, so evidence about one should not be presented as evidence that the other is complete.

The concise distinction is a pair of questions: what entity has been established, and what may that entity do here? Keeping both questions visible makes account settings, sharing rules, and access errors easier to interpret without treating every denial as a failed login.