JHED Authentication vs. Authorization: Why a Successful Login Is Not the Same as Access

A person can successfully sign in with a JHED identity and still be denied access to an application.

This can appear contradictory until authentication and authorization are treated as separate processes.

Authentication answers:

Is this person successfully proving the identity associated with this account?

Authorization answers:

Is this authenticated identity allowed to access this particular resource?

A central institutional identity can solve the first question without automatically answering the second.

Authentication establishes the identity context

Johns Hopkins describes JHED as part of its institutional identity environment and uses the identity across supported systems and services.

When a user authenticates successfully, the institutional environment can recognize the identity that is attempting to access a resource.

This does not mean that the resource has decided to grant access.

Authentication establishes who the system believes the user is. The application can then apply its own access rules.

Authorization evaluates the requested resource

After authentication, an application may determine access based on factors such as:

• institutional role;
• department;
• employment status;
• enrollment status;
• assigned permissions;
• security groups;
• administrative approval;
• training requirements;
• application-specific business rules.

The same JHED identity can therefore receive different results from different systems.

That is normal in a controlled institutional environment.

Why users often blame the login

From the user’s perspective, the process can look simple:

1. Open an application.
2. Sign in.
3. Receive “Access Denied.”

The natural conclusion is that the login failed.

But if the authentication stage was successful, the failure may actually have occurred after the identity was verified.

This distinction matters because a password reset is unlikely to solve a missing authorization problem.

A simple example

Imagine two employees:

Employee A

• Has a valid JHED identity.
• Successfully authenticates.
• Works in the department that owns the application.
• Has the required role.

Employee B

• Also has a valid JHED identity.
• Successfully authenticates.
• Does not work in that department.
• Has not been assigned the required role.

Both identities are valid.

Only one may be authorized.

The difference is not the existence of JHED. The difference is the entitlement attached to the requested resource.

Authentication failures and authorization failures look different

An authentication issue may involve:

• an unknown identity;
• invalid credentials;
• a password problem;
• multifactor authentication;
• an identity-service failure.

An authorization issue may involve:

• successful sign-in followed by denial;
• missing permissions;
• the wrong institutional role;
• incomplete provisioning;
• access assigned to another group;
• expired or removed authorization.

These should not be sent through exactly the same troubleshooting process.

Central identity does not mean universal access

Large institutions need central identity systems because many people use many applications.

However, granting every authenticated user access to every application would create an obvious security problem.

Central authentication therefore works best when combined with controlled authorization.

The identity establishes a consistent way to recognize the person. Individual systems can then determine what that person is permitted to do.

Why administrators should separate the two processes

When an administrator receives an access request, the first question should be:

Is this an identity problem or an application-permission problem?

If authentication is failing, the central identity or authentication layer may need investigation.

If authentication succeeds but access is denied, the application owner or designated access administrator may be the more appropriate source of support.

This separation prevents the central identity system from becoming the assumed owner of every application-level problem.

The practical diagnostic sequence

When access fails, ask:

1. Does the user have the correct institutional identity?

If not, investigate identity provisioning.

2. Can the user authenticate successfully?

If not, investigate the authentication layer.

3. Which application is rejecting access?

Identify the exact resource.

4. Does the user have the required role?

Check authorization.

5. Who owns that role?

The responsible department or application administrator may need to make the final access decision.

The key principle

A valid identity proves who the user is.

A successful login proves that the user has authenticated.

Neither automatically proves that the user should be allowed to access a particular institutional resource.

Understanding that distinction is the foundation of effective JHED access management.

Related articles:

• JHED Access Governance: Who Actually Decides Who Gets Access?
• Why Your JHED Login Works but an Application Still Says You Do Not Have Access
• The JHED Account Lifecycle: Provisioning, Review and Deprovisioning
• Sponsored JHED Accounts vs. Guest Accounts