Authentication vs Authorisation: Why Signing In Does Not Mean You Have Access

Understand identity checks, permissions, and access policies — and investigate Microsoft cloud access problems with better evidence.

By Abdulmajid Abdurrahim
Cloud Administration in Practice — Article 2
Sources checked: 1 October 2026

Authentication vs Authorization

A staff member signs in to Microsoft 365, completes the authentication prompt, and opens their email. Then they follow a link to a finance document and receive an access-denied message.

“Is there something wrong with my password?” they ask.

In this fictional example, the account works. The next question is whether that account has permission to open that particular document.

Understanding the difference between authentication and authorization helps administrators investigate the right problem. It also helps developers avoid treating a successful login as permission to use every feature in an application.

Authentication checks who is signing in

Authentication verifies a claimed identity. Microsoft documentation sometimes abbreviates it as AuthN. [1]

A user might authenticate with a password, a passkey, or another supported method. Multifactor authentication (MFA) strengthens identity verification by requiring more than one factor. It does not assign a business role or grant access to a document. [1]

Think of a visitor arriving at an office. Reception checks their identification and confirms who they are. That check does not give the visitor permission to enter every room.

Similarly, proving that an employee is the person associated with an account does not establish which company information they should see.

Authorization checks what that identity may do

Authorization determines the permitted actions and resources. Microsoft documentation sometimes abbreviates it as AuthZ. [1]

Permission can be specific: read a file, edit a record, manage a virtual machine, or administer a directory. Different Microsoft services use different authorisation systems.

The table is a starting point for investigation, not a complete list of every control that can affect access. [2][3][4][5]

Scenario 1: Email works, but a finance document does not

Return to the fictional employee. Their successful email access establishes that one service interaction works. It does not establish access to the finance document.

SharePoint supports access through site membership and sharing permissions, with files or folders sometimes having permissions that differ from their parent. [2]

The administrator should confirm the exact account in use, the document being requested, and the permission path that should grant access.

Perhaps the employee is using a different account in the browser. Perhaps they are outside the approved finance group. Perhaps the link was intended for specific recipients.

These are hypotheses to check. They are not reasons to immediately reset a password or make the employee a site owner.

The appropriate outcome may be granting approved access — or explaining that the restriction is intentional.

Scenario 2: An engineer signs in to Azure but cannot change a resource

Azure role-based access control, or RBAC, governs access to Azure resources. A role assignment combines a security principal, a role definition, and a scope. [3]

Those terms answer three practical questions:

• Who? The user, group, service principal, or managed identity.
• What actions? The permissions described by the role.
• Where? The resource, resource group, subscription, or management group covered by the assignment.

In a simplified example, an engineer with Reader access to a test resource group can view its resources but cannot modify them through that role. Successful sign-in does not change the role’s permissions. Other applicable assignments must also be considered when assessing effective access. [3]

There is another boundary to remember: Entra directory roles and Azure resource roles are separate. By default, a Global Administrator does not automatically have access to Azure resources. Microsoft documents an explicit elevation mechanism, but ordinary access should be assessed through the relevant role system. [4]

Conditional Access adds another decision

A correct password does not necessarily mean the full sign-in or access process will succeed.

Microsoft Entra Conditional Access evaluates signals such as the user, application, location, and device. Depending on policy, it can require additional authentication, require a compliant device, or block access. Microsoft states that these policies are enforced after first-factor authentication. [6]

Get Abdulmajid Abdurrahim’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

For example, an employee may enter the correct password while using a device that fails a policy requirement.

That is a policy-related access problem. Adding a SharePoint permission may leave it unresolved.

The useful distinction is:

• Identity verification: Has the claimed identity been verified?
• Access conditions: Have the applicable policy requirements been satisfied?
• Resource authorization: Is the requested action permitted?

These questions are a troubleshooting framework. Actual applications can evaluate controls at several points, including during later resource requests.

Developers need the distinction too

Applications can receive different kinds of tokens.

An ID token carries information about the authenticated user for the client application. Microsoft explicitly advises against using it to call an API. [7]

An access token is presented to its intended protected API. That API must validate the token and enforce the relevant authorization requirements. Possessing a token is not permission to perform arbitrary actions against any service. [8]

Microsoft’s permissions model also distinguishes delegated permissions, used by an application on behalf of a signed-in user, from application permissions, used without a signed-in user. Consent requirements vary with the permission and tenant configuration. [5]

For developers, a visible login screen is only one part of protecting a system. The backend must also check access to the requested data and actions.

A better access-troubleshooting workflow

Before changing anything, collect the account, resource, attempted action, time, error message, and recent relevant changes.

Then investigate in this order:

1. Confirm the account and tenant. Check that the user is acting as the intended identity in the intended organization.
2. Review the relevant sign-in event. Entra sign-in logs help identify the user, client application, target resource, and sign-in errors. Match the event to the actual attempt. [9]
3. Check policy requirements. Review the applicable authentication and Conditional Access information rather than assuming the password is wrong.
4. Inspect resource permissions. Check the correct permission system, role, group membership, and scope.
5. Check service-specific requirements. Investigate licensing, application configuration, or resource availability where relevant; the AuthN/AuthZ distinction does not explain every failure.
6. Make an approved, limited correction. Grant only the access needed for the task.
7. Verify the boundary. Confirm the intended task works and an unrelated restricted task remains blocked. Record the change and remove temporary access when no longer needed.

A successful sign-in log helps establish what happened during that sign-in. It does not prove that a later file request or API operation was authorized.

The practical lesson is to name the requested action precisely. “The user cannot access the system” is less useful than “this account can sign in, but cannot read this document.” That sharper description gives the investigation a direction.

Next in this series: Read an Entra Sign-In Log Before Resetting Another Password.

Sources

Primary sources: Microsoft Learn. All accessed 1 October 2026.

1. Authentication vs. authorization.
2. Sharing and permissions in the SharePoint modern experience.
3. What is Azure role-based access control?.
4. Azure roles and Microsoft Entra roles.
5. Overview of permissions and consent.
6. Microsoft Entra Conditional Access overview.
7. ID tokens in the Microsoft identity platform.
8. Access tokens in the Microsoft identity platform.
9. Sign-in logs in Microsoft Entra ID.