Explain sign-in by following the user request through the application, identity provider, and access decisions.
You don't need to begin with protocol definitions. Start with who is asking for access and which system makes each decision. Then use the terminology to describe what you actually observed.
The user may experience one click and a prompt, while several components participate. A simple flow diagram helps you separate those stages and explain why a failed login isn't always a password problem—or proof that the application itself is unavailable.
The application first needs to establish who you are
In a common federated sign-in, the application directs the browser toward an identity provider it trusts. The identity provider handles the relevant authentication process.
That process might involve a password, a passkey, an existing authenticated session, or additional verification. The precise sequence depends on the implementation and policy.
The important distinction is that the application is not necessarily checking your password itself. It may rely on a trusted identity system to provide a result.
Microsoft's protocol overview is a useful reference for the parties involved in an OAuth and OpenID Connect flow.
Separate authentication from the conditions for access
Establishing an identity is one part of the flow. The environment may also evaluate conditions before access continues.
Keep three ideas distinct in your explanation:
- Identity established: What evidence satisfied the authentication process?
- Additional conditions: Did a policy require another step or restrict the request?
- Observed outcome: Which condition did your test actually exercise?
A request may require an additional authentication step or be restricted under particular conditions. That is why “the login failed” isn't a diagnosis of a bad password.
Stay specific to the system you've built or investigated. Name the policy condition you tested rather than listing every feature the product supports.
On your diagram, show authentication and access-condition evaluation as separate ideas. That makes it easier to explain which stage completed and where further evidence is needed.
The application receives and validates an identity result
In an OpenID Connect implementation, an ID token carries identity information for the client. Other protocols use different messages and terminology.
The receiving application must validate the result according to the protocol and its configuration. A message arriving in the browser does not automatically mean the application should trust it.
Microsoft explains the role of the ID token in its OpenID Connect documentation. For a career discussion, focus first on who issued the result, who should receive it, and why the receiver accepts it.
Do not paste live tokens into your portfolio or an unapproved online decoder. Treat them as sensitive material.
The application still controls what you can do
After sign-in, the application may create its own session and determine what functions the user can access.
A user might sign in successfully but lack permission to approve an invoice. That is not the same failure as being unable to authenticate.
This is why “SSO works” and “the user's access is correct” should be tested separately.
The difference between authentication and authorization is worth understanding before you try to explain a complicated integration. It prevents several stages from collapsing into one vague statement about logging in.
Practice with one successful flow and one failure
Draw the normal path for a test application. Label the user, browser, identity provider, application, and the key messages or redirects you can actually observe.
Then introduce one safe, reversible configuration error in the isolated lab. Record where the flow stops and which system has the most useful evidence.
Your explanation should answer what happened, where it happened, and why you investigated that stage first. Avoid claiming that every application follows your exact diagram.
The SSO project in The Six-Figure IAM Career Playbook gives this learning a career purpose alongside role selection and portfolio guidance. The $9 book helps you turn an everyday login into something you can explain and demonstrate.
A clear sign-in explanation is not protocol trivia. It is a map you can use when the login stops working.