Last reviewed:
An identity provider (IdP) authenticates users and issues the federated tokens your cloud accounts trust. Okta, Entra ID and IAM Identity Center are common ones.
An identity provider (IdP) holds user identities and authenticates each sign-in attempt, then asserts the result to the applications that rely on it. Those applications are the service providers (SPs); the IdP and SP establish trust through SAML assertions or OIDC tokens instead of sharing a password. Single sign-on (SSO) is the user-facing outcome of that trust, where one authenticated session is reused across many service providers.
When a user signs in, the IdP validates their credentials and returns a signed assertion (a SAML response or an OIDC ID token) carrying claims about who the user is and which groups they belong to. The service provider checks that signature against the IdP's published keys and grants access based on the claims. This is why a compromised or misconfigured IdP signing key undermines every application that trusts it.
Common cloud identity providers include Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, Ping Identity and AWS IAM Identity Center (formerly AWS SSO). Each verifies a user with a password, MFA factor, passkey or certificate, then federates that identity into downstream AWS, Azure and GCP accounts. AWS IAM also lets you register an external IdP directly as a SAML or OIDC identity provider attached to a role, so an Okta or Entra login can assume an AWS role without a standalone IAM user.
IdP logs are a high-value detection surface. Anomalous sign-in patterns, failed-MFA bursts, unfamiliar source IPs, impossible-travel events and federated-trust abuse all surface in IdP logs before they reach cloud audit logs. CloudSigma generates Sigma rules for the major IdP signal sources, including the Okta System Log, Entra Sign-in Logs and Entra Audit Logs.
In MITRE ATT&CK terms, IdP abuse maps to techniques such as T1078.004 Valid Accounts: Cloud Accounts and T1556 Modify Authentication Process. Because the IdP is the single trust anchor for every federated account, detection coverage over its logs is a prerequisite for trusting any signal from the cloud accounts that sit downstream of it.
The identity provider (IdP) authenticates the user and issues a signed assertion about who they are. The service provider (SP) is the application or cloud account that consumes that assertion and grants access. They exchange trust over SAML or OIDC, so the SP never handles the user's password. One IdP typically serves many service providers, which is what makes single sign-on possible.
Widely used cloud identity providers are Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, Ping Identity and AWS IAM Identity Center. Each authenticates users and federates that identity into AWS, Azure and GCP accounts using SAML or OIDC. Many organisations run one primary IdP and connect every cloud platform and SaaS application to it, so access is governed in one place.
AWS IAM Identity Center acts as an identity provider for AWS accounts, and IAM can also trust an external IdP such as Okta or Entra ID registered as a SAML or OIDC identity provider. In that federated setup a user authenticates at the external IdP and then assumes an IAM role, so no standalone IAM user or long-lived access key is needed.