SSOGEN / Learn / Authentication vs Authorization: Who Are You, and What May You Do?

Learn

Authentication vs Authorization: Who Are You, and What May You Do?

Authentication vs authorization is the difference between proving who you are and being allowed to do something. Test yourself below, then follow one request through both decisions.

Updated Oct 8, 2026

Request More Info

Authentication vs authorization comes down to two questions. Authentication asks “who are you?” and ends with a verified identity. Authorization asks “what may you do?” and ends with a yes or a no for one resource or action.

They happen in that order, and different parts of a system usually decide them. The failures differ as well:

Failed authentication: the system does not know who you are.
Failed authorization: the system knows who you are and refuses the request.

Test yourself first

The quiz has eight everyday scenarios, from a password and a phone prompt to an AI agent asking for a tool. Pick authentication or authorization for each, then read the feedback.

It runs entirely in your browser, keeps no score and sends nothing.

Two scenarios are deliberately ambiguous, and they are the ones most people get wrong.

Question 1 of 8

The policy question about stronger factors is the one most often missed. The next section explains why.

Follow one request through both decisions

A single request shows the split more clearly than definitions do. Maria Lopez, in finance at Acme Corp (acme.example), selects the “Acme Payroll” tile in My Apps.

SSOGEN makes one decision, built from several smaller questions asked in a fixed order. The first question that fails ends the request.

The questions and messages come from the SSOGEN guide to how sign-in decisions work, the access rules guide and rules and conditions.

Step	Question asked	Decided by	What happens on a no
1. Authentication	Is she who she says she is?	The identity provider she signed in at (company directory, Entra ID, Okta or SSOGEN itself)	The provider refuses and she never gets a session. Nothing else is asked.
2. Authorization	Is she assigned to Acme Payroll, directly or through a group?	The application’s assignments	“You are not assigned to this application.” Signing in more strongly does not change this.
3. Authorization	Is the application switched on and finished?	The application’s state	The tile is greyed and says Unavailable or Not set up yet.
4. Authorization	Does the application’s policy allow any identity provider at all?	The policy	“No sign-in method is allowed for this application yet. Please ask your administrator.”
5. Authorization	Do the organization-wide access rules allow her? First matching rule decides.	Access rules (SSO Policies > Defaults)	“Access to this application is not allowed.” A contractor in no allowing rule meets the default Deny here.
6. Authorization	Do the policy’s own rules allow her? Network, time of day, group, risk score.	Policy conditions	Same message, or a shorter session, or an alert, depending on the rule’s outcome.
7. Authentication	Is the sign-in strong enough, recent enough, from an allowed provider?	The policy’s required strength	She is sent to prove more: an authenticator code or a passkey. If she does not finish: “Additional verification was not completed, so the application was not opened. Try again.”

Authentication appears at both ends of the table. Step 1 establishes an identity. Steps 2 to 6 decide whether that identity may open this application, from here, now.

Step 7 returns to authentication. The access decision was “yes, but only with stronger proof than you gave.” This is the case that most often trips people in the quiz:

The policy decides that a second factor is needed (authorization).
The factor itself is the proof (authentication).

Two details matter:

Both rule lists are read and the strictest answer wins. A Deny in the access rules or in the policy refuses, even if the other list says Allow. An Allow in the access rules does not skip the policy’s own requirements.
A rule can only ask for more, never less. SSOGEN does not save a rule that would lower the strength a policy asks for.

When SSOGEN cannot establish a fact, such as a rule that names a group that no longer exists, it refuses rather than defaulting to yes. Authorization that fails open is where security gaps appear.

The same question for an AI agent

An agent has no password and no biometrics. It authenticates with a key pair, and every token SSOGEN issues to it is tied to that key and lives about four minutes.

The real control is in authorization, as the guide to AI agent access control describes.

Step	Question asked	Decided by	What happens on a no
1. Authentication	Does the agent hold the registered private key?	The agent’s registered public key	No token is issued.
2. Authorization	Is the agent active, inside its expiry and review dates, and its type’s kill switch off?	The agent’s record	Refused. An agent whose last owner left is suspended: “Suspended: its owner left. Add an owner before reactivating.”
3. Authorization	Is every scope it asks for inside its grant?	The grants the owner set on the application	Refused. SSOGEN never silently narrows an out-of-grant scope.
4. Authorization	Does policy allow this agent to reach this application?	Policy rules, including who is asking: person, AI agent, MCP client, automation or service	Refused with a policy message.
5. Authorization	For an agent acting for Maria: did she agree, and does she still have that access?	Her delegation	The agent gets only the part of its grants she approved.
6. Authorization	Is the scope marked Sensitive?	Maria, at that moment, on her Approvals page	The request waits, then ends as `access_denied` or `expired_token`.
7. Authorization	Is this tool named in a scope the agent holds?	The MCP Gateway, on each tool call	403 with `insufficient_scope`.

Authentication takes one step here and authorization takes six. That ratio is typical for software that acts on its own.

Where the two get mixed up

Four mix-ups cause most of the confusion.

OAuth is authorization. OpenID Connect adds authentication. RFC 6749, read 2026-10-08, describes OAuth 2.0 as a framework for limited access to an HTTP service. OpenID Connect Core 1.0, read the same day, adds an identity layer on top.

A SAML assertion carries both who and what. The assertion defined in SAML 2.0 Core, section 2, can hold an authentication statement (when and how the person signed in) next to attributes such as email and groups.

A token proves you signed in, not that you may perform this action. A valid ID token or session cookie answers step 1. It says nothing about whether this person may approve this invoice.

Stronger sign-in is not more permission. A passkey proves the person’s identity more firmly, but it never grants access they were not assigned. In SSOGEN, a stronger sign-in never creates an assignment.

Details behind the OAuth and OpenID Connect split

Authentication is out of scope for OAuth. How the authorization server authenticates the resource owner is, in the RFC’s words, beyond its scope (section 3.1).
An access token is not an identity. It represents an authorization issued to the client (section 1.4). It does not identify the user.
OAuth lets a third-party application obtain access. RFC 6749 describes it as a framework that lets a third-party application obtain limited access to an HTTP service.
OpenID Connect adds the identity layer. It lets a client verify the end user’s identity, based on the authentication the authorization server performed.
The ID token states how. It can carry auth_time, acr and amr to state when and how the user authenticated.

See OIDC vs OAuth for the comparison and What is OAuth 2.0 for the roles and grant types.

Details behind the SAML and token mix-ups

SAML attributes are not grants. The authentication statement is authentication. Whether the attributes grant anything is the application’s authorization decision, made after it accepts the assertion.
A valid token is not a permission check. An API that checks only that a token is valid, and not the scope or the record’s owner, is running an authentication check in place of an authorization check.

Why AI agents make the difference matter

With a person, a weak authorization check is often masked by the fact that the person has a job and a manager. An agent has neither, and it can make thousands of calls an hour. Three things change.

Identity is cheap to get right; permissions are not. An agent with a registered key and an owner is authenticated cleanly. What it may do is a separate list of applications and scopes, which someone has to write and keep small.
The right unit is the action, not the session. A person who signed in at 9:00 is still that person at 15:00. An agent that may read invoices must not approve them only because it holds a valid token.
Acting for someone is two identities at once. When an agent acts for Maria, both identities must pass. The delegation never gives the agent anything Maria does not have.

SSOGEN checks each tool call against the scopes granted, and it marks a scope Sensitive when a human should decide at the moment of use.

It checks the conditions on who is acting separately for each acting identity. Read more at AI agent identity.

Ten questions to tell which problem you have

Use these when you review an application, a ticket or an incident. Answer “yes,” “no” or “don’t know.” Questions 1 to 5 cover authentication and 6 to 10 cover authorization. Every “don’t know” is a finding.

Can you name every way a user can prove who they are to this application (password, SSO, passkey, API key)?
Does the application accept an identity from one source, or can a user create a second account that bypasses your provider?
Is the strength of the sign-in decided by a policy, or by whatever each user happens to pick? See adaptive authentication.
Do service accounts and AI agents have an owner and an expiry, or a shared password?
When a sign-in is unusual (new browser, new network), does anything ask for more proof?
Does the application check what this person may do on every request, or only that a session exists?
Is access granted by a role or group someone reviews, or by a list buried in the application?
If a rule cannot be evaluated, does the application refuse or let the person through?
Can a sensitive action require a fresh approval, separate from the sign-in?
Can you answer “who could do X last Tuesday, and who actually did” from a log?

Mostly “no” to 1 to 5. The problem is authentication: the system does not know who is asking.
Mostly “no” to 6 to 10. The problem is authorization: the system knows who is asking but has no reliable answer on what they may do.

Most real environments have both.

How SSOGEN separates the two

SSOGEN is a complete identity provider. It also connects to the identity providers you already run, so authentication can stay where it is.

The policy engine makes the access decision on every launch. It evaluates:

the assignment;
the organization-wide access rules;
the per-application policy rules;
the required sign-in strength.

It also computes a deterministic risk score from 0 to 100 that a rule can read.

The What if page shows the whole chain for any person and application, rule by rule, so you see which step would refuse before anyone is affected.

For AI agents, the same engine adds owned identities, scopes, delegation and approvals. Start with how sign-in decisions work.

Questions people ask

Can you have authorization without authentication?

Only if the decision does not depend on who is asking, as with a public page. Any per-person decision needs an identity first.

Is MFA authentication or authorization?

Authentication: it strengthens the proof of identity. A rule that requires MFA is an authorization-side decision that triggers it.

Which comes first?

Authentication, then authorization. A policy can then ask for more authentication, so the two interleave.

Is a role an authentication or an authorization concept?

Authorization. A role says what an identity may do, not who it is.

Where to go next

OIDC vs OAuth. Compare the two standards.
AI agent identity. See how agents get their own identity.
RBAC vs ABAC. A role is one way to decide what someone may do; this compares it with deciding by attributes such as department, time and device.

Sources, all read 2026-10-09: RFC 6749, OpenID Connect Core 1.0, SAML 2.0 Core.