A failed login can occur before authentication, during the identity provider's checks, or after the application receives a response.
Locate the failed stage before changing a password or permission. That is easier when you can explain the path from clicking Sign In to using the application.
The example below follows a simplified OpenID Connect integration with an identity provider. It isn't a universal description of every application. Use it to understand the decisions and boundaries, then compare those with the system you're investigating.
The application needs an identity it can trust
A user opens the application. The application needs to establish who the user is, so it directs the browser into an authentication flow with the configured identity provider.
The exact requests depend on the implementation. Modern applications should use supported authentication libraries and documented patterns rather than improvised security code.
For this explanation, keep three parties visible: the user and browser, the application, and the identity provider.
Draw them before adding the protocol details. If you can't identify which system owns a step, the rest of the troubleshooting will be guesswork.
The identity provider handles its authentication process
The user completes whatever authentication the configuration requires.
That may involve more than a password. It may also involve checks that determine whether this particular sign-in should proceed.
Don't assume that seeing a login page means the application itself is validating the password.
The distinction matters when diagnosing a failure. A problem before authentication completes points you toward different evidence than a problem after the application receives a response.
Record the actual symptom and the time of the attempt rather than jumping to a reset.
The application receives and validates identity information
In an OIDC flow, identity information is conveyed through an ID token. The application must validate the relevant response and token using the supported implementation. Microsoft's documentation describes ID tokens and the claims they contain. Source: Microsoft OpenID Connect.
An ID token and an access token are not interchangeable labels for the same purpose.
Access tokens are used when requesting access to protected resources. Keep that distinction visible instead of calling every token a “login ticket.” Source: Microsoft access tokens.
Do not paste live tokens into public notes, screenshots, or unapproved analysis tools. They can contain sensitive information or act as credentials.
For a portfolio, use diagrams and sanitized evidence.
The application still decides what the user can do
Knowing who signed in doesn't mean giving them every feature.
The application may use assigned roles, its own permissions, or another access model to determine the allowed actions.
That is why “authentication succeeded, but access failed” is a coherent problem.
You should ask whether the user is entitled to the application, whether the relevant role is present, and how the application evaluates it.
The exact checks depend on the system. A successful identity-provider event and an application error can both be accurate at the same time.
Use the symptom to identify the stage that failed
Three users can all say “I can't log in” while experiencing different problems:
| Symptom | Where to begin the investigation |
|---|---|
| The browser never reaches the expected identity provider | The path and configuration leading to authentication |
| The identity provider rejects the sign-in | Its authentication checks and available error evidence |
| The application receives a response but refuses access | Response validation, application assignments, or authorization as applicable |
These are starting points, not diagnoses. Inspect evidence you're authorized to access before deciding on a correction.
In a test environment, change one relevant setting at a time and record whether the new result supports your hypothesis. If it doesn't, reconsider the explanation rather than stacking unrelated changes.
Don't weaken security controls merely to remove the error screen. A successful sign-in still needs to satisfy the intended access requirements.
Turn the flow into a project explanation
A useful lab page can show the normal path, one controlled failure, and the steps used to diagnose it.
Explain which system produced the error and why the correction was appropriate. Include the limits of the demonstration.
You don't need to implement the protocol yourself to understand the responsibilities at each boundary.
The Six-Figure IAM Career Playbook includes a single sign-on project designed to help you build that kind of practical evidence. The ebook is $9.
The next time someone says “the login is broken,” you can ask a better question:
Which part of the sign-in—and what evidence shows us that?