This video walks through the architecture of an Identity Provider — how the directory, SSO, MFA, and provisioning components fit together and what happens at each step when a user logs in. No configuration, no hands-on setup. Just the architecture, explained visually so you understand the system you are auditing.
Conceptual walkthrough
You do not need an account with any IdP to follow along. This is a conceptual walkthrough of how identity providers work under the hood — the flows and components, not the admin console.
Identity Provider Architecture Walkthrough
How an IdP sits between users and applications
The IdP is a broker. Users never authenticate directly to an application. Instead, the application redirects the user to the IdP, the IdP authenticates them, and the IdP sends a signed assertion back to the application confirming who the user is and what groups they belong to.
This broker model is what makes centralization possible. Applications do not store passwords. They do not manage MFA. They do not maintain user directories. They trust the IdP to handle all of that, and they accept the signed assertion as proof of identity.
From a GRC perspective, this architecture means there is one system to audit for authentication controls, one audit log to review for access events, and one place where a disabled account means disabled access everywhere.
The directory as source of truth
At the core of every IdP is a user directory. This is the authoritative database of identities — every employee, contractor, and (depending on the IdP) service account in the organization.
Each directory entry contains attributes: name, email, department, manager, job title, employment status, group memberships. Groups are the primary mechanism for access control. Instead of assigning applications to individual users, you assign applications to groups. "Engineering" gets GitHub and AWS. "Sales" gets Salesforce and HubSpot. "Everyone" gets Slack and Google Workspace.
When an auditor asks "who has access to your production AWS account," the answer should be traceable from the IdP directory: a group called "Production-AWS-Admins" is assigned to the AWS application, and here are the five people in that group.
How SSO flows work at a high level
The SSO flow has three actors: the user, the IdP, and the application (called the Service Provider or SP in SAML terminology).
The flow works like this: the user navigates to the application. The application recognizes the user has not authenticated and redirects the browser to the IdP. The IdP presents a login screen (or recognizes an existing session). The user authenticates. The IdP evaluates policies — does this user need MFA? Is their device compliant? Are they on an approved network? The IdP generates a signed assertion containing the user's identity and attributes. The browser carries this assertion back to the application. The application validates the signature, reads the assertion, and grants access.
The user experiences this as one login that works everywhere. The GRC Engineer sees a single authentication event in the IdP audit log, a policy evaluation, and a signed assertion — all auditable.
Where MFA is enforced in the flow
MFA happens at the IdP, during the authentication step — before the signed assertion is generated. The IdP's authentication policy determines when a second factor is required.
Common policy configurations include: require MFA for every login, require MFA only when the user is on an untrusted network, require MFA for specific applications classified as high-sensitivity, require step-up MFA when the sign-in risk score exceeds a threshold (Entra ID's Conditional Access does this), or require MFA only at the start of a session and then trust the session for a defined period.
The critical point for compliance: MFA enforcement at the IdP layer applies to every connected application. You do not need to configure MFA in Slack, GitHub, AWS, and Jira separately. You configure it once in the IdP, and every SSO flow inherits the policy. This is what makes centralized MFA auditable — one policy export from the IdP proves MFA enforcement across all applications.
Provisioning and deprovisioning with SCIM
SCIM — System for Cross-domain Identity Management — is the protocol that automates account creation and removal across applications. When an IdP supports SCIM and an application supports SCIM, the IdP can automatically create a user account in the application when the user is assigned, update the account when attributes change, and deactivate the account when the user is removed.
Without SCIM, SSO handles authentication but not provisioning. The user can log in via SSO, but someone still has to manually create their account in each application and manually disable it when they leave. SCIM closes that gap.
For GRC, SCIM provisioning is the mechanism behind automated offboarding. When HR marks an employee as terminated in the HRIS, the IdP receives that signal (either through a direct integration or a workflow), disables the user's IdP account, and SCIM propagates the deactivation to every connected application. The timestamp on each deactivation event is the evidence that offboarding happened within the required SLA.
Audit evidence
When pulling evidence from an IdP during an audit, you are typically asked for five things: the complete user list with status (active/inactive) and last login date, the list of applications connected to the IdP with their SSO configuration, the MFA enrollment report showing which users have MFA registered and which factors they use, the authentication policy configuration showing when MFA is required, and the audit log showing recent authentication events and administrative changes. These five exports cover the majority of identity-related SOC 2 and ISO 27001 evidence requests.
Key takeaways
The IdP architecture is not complicated, but understanding it precisely matters when you are auditing controls or writing control narratives. The directory is the source of truth. SSO delegates authentication to the IdP so applications never handle passwords. MFA is enforced at the IdP layer and inherited by every connected application. SCIM automates provisioning and deprovisioning so that access revocation is immediate and auditable.
The next lesson provides a detailed comparison matrix across all four major IdPs — a reference you can use when evaluating which IdP an organization should adopt, or when assessing how well their current IdP covers compliance requirements.