In a federated sign-in, the identity provider helps establish identity, while the application uses the supported flow to recognize the user and participate in access decisions.
In SAML, the application side is commonly called the service provider. Related protocols use different terms, so learn the vocabulary for the flow you're actually using.
Follow one fictional employee into one application. The relationship becomes easier to understand when each definition has a role in a visible sequence.
Start with the application the user wants to open
Imagine an employee opening a test expense application.
The application needs a way to recognize the user. Instead of asking the application to independently maintain every part of the authentication process, the integration directs the user through a trusted identity system.
That identity system is the identity provider in the scenario.
The important point is the relationship: the application is configured to rely on identity information from a particular provider under a defined protocol and configuration. It should not accept arbitrary assertions from anywhere.
Follow the identity-provider stage without assuming every prompt is identical
The configured flow brings the user to the identity provider for the required authentication process.
Ask three questions:
- Identity: What information is being established for this request?
- Requirements: Which relevant authentication conditions apply?
- Return: How does the supported integration convey the expected information back?
The details vary by platform, policy, and protocol. An existing session can also change the visible user experience.
Don't assume every successful sign-in requires the same fresh prompts. Equally, the browser view alone may not expose every decision involved.
Use the platform's supported documentation and your lab evidence together. Your explanation should distinguish what the user sees from what the integration requires, while avoiding claims about unobserved behavior that your test didn't establish.
Understand what the application receives
In a SAML flow, the application receives a response containing an assertion that it must validate appropriately.
Microsoft's SAML single sign-on protocol documentation describes one implementation of the exchange and its relevant fields.
You don't need to memorize every field before understanding the basic relationship. You do need to recognize that the application must evaluate whether the response is valid and intended for the configured integration.
A response arriving in the browser is not, by itself, proof that the application should trust it.
Keep application access separate from identity recognition
After recognizing a user, the application may still need to determine what that user is allowed to do.
A person might sign in successfully but lack the role required to approve an expense report. Another might not have an application account or assignment required by the particular design.
Those are related access questions, but they are not identical to authentication.
This distinction helps explain why an application owner and identity engineer may inspect different evidence when the same user reports that “login is broken.”
Learn the terminology for the protocol you are using
SAML's identity provider and service provider terminology does not map word for word onto every other protocol.
For OpenID Connect, you will encounter terms such as OpenID Provider and relying party or client. Learn the specific model from the documentation for the protocol and implementation you are testing.
Use a practical comparison of SAML and OpenID Connect when you are ready to distinguish the flows more carefully.
The goal is a correct mental model, not using one familiar term for every component in every system.
Build a diagram before a complicated lab
Draw the user, identity provider, and test application. Label the important exchanges and indicate where authentication and application access decisions occur.
Then use a safe test integration to compare the diagram with an observed successful sign-in. Add a controlled failure only after the baseline is clear.
Document which components you configured and what the platform handled automatically.
The Six-Figure IAM Career Playbook includes a practical SSO lab direction and connects identity fundamentals to portfolio evidence. The $9 guide helps you move from knowing the words to having a flow you can explain.
Once you understand who relies on whom and for which decision, the terminology becomes much easier to remember accurately.