What Is a SAML IdP? Providers, Examples, and 2026 Security Checks

A SAML IdP (identity provider) is the trusted system, such as Okta, Microsoft Entra ID, Google Workspace, or Keycloak, that verifies a user’s identity and sends a digitally signed XML assertion to an app (the service provider), so the app never sees the password. Because every connected app relies on it, the IdP is where MFA, access policy, and certificate trust are managed, and where recent SAML attacks have concentrated.

What is a SAML IdP?

A SAML IdP (identity provider) is the system that verifies who a user is and then sends a digitally signed XML assertion to an application, called the service provider (SP). The user signs in without the app ever handling their password. Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, and Keycloak are the most widely deployed SAML IdPs.

The protocol is the OASIS SAML 2.0 standard, which OASIS members approved on March 14, 2005. The current US federal baseline for assertions is NIST SP 800-63C-4, finalized July 31, 2025. At its lowest federation level (FAL1), the IdP must sign the assertion with approved cryptography, and the app must validate that signature with the expected IdP’s key.

SAML IdP verdict at a glance

Question	Answer
Setup difficulty	Low with a managed cloud IdP (import metadata, map attributes). Medium to high when self-hosted (Keycloak, Shibboleth, AD FS). High if you build your own IdP.
Best fit	Browser-based workforce SSO and B2B federation between organizations
Poor fit	Native mobile apps and API authorization, where OIDC and OAuth 2.0 fit better
2026 risk reality	Recent SAML breaches trace to SP library parsing bugs and exposed IdP appliances, not to the SAML standard itself
Ongoing work	Signing certificate rotation, metadata refresh, SAML library patching
Who should read on	SaaS developers adding enterprise SSO, IT admins choosing or configuring an IdP, security teams checking exposure

What does a SAML identity provider actually do?

A SAML IdP does six jobs:

• Authenticates the user. SAML does not prescribe the method, so the IdP can use a password, MFA, a passkey, or a smart card.
• Holds or connects to the directory, such as Active Directory, LDAP, or its own user store.
• Builds the assertion. It carries the user identifier (NameID), when and how the user authenticated, attributes such as email and groups, and validity conditions.
• Signs the assertion with its private key, and can also encrypt it for one specific SP.
• Publishes metadata: an XML file with the IdP’s entity ID, SSO URL, and public signing certificate.
• Enforces access policy once for every app: MFA, device checks, and conditional access.

That central position makes the IdP the main target for password attacks. In Verizon’s analysis of SSO provider logs, credential stuffing made up a median of 19% of all daily authentication attempts. It also makes the IdP a single point of failure: if it is down or its certificate expires, every connected app stops accepting logins.

Read the full guide: What Is SAML? How SAML Works, How SAML Is Used, and Where It Breaks

What is the difference between a SAML IdP and an SP?

The IdP proves identity; the SP consumes that proof and grants access.

Aspect	Identity Provider (IdP)	Service Provider (SP)
Role	Authenticates the user	Hosts the app the user wants
Holds credentials	Yes	No
Message it sends	SAML Response containing the Assertion	AuthnRequest (SP-initiated flows only)
Cryptographic job	Signs, optionally encrypts	Validates the signature, optionally decrypts
Key endpoint	SSO URL (login endpoint)	ACS URL (Assertion Consumer Service)
Examples	Okta, Microsoft Entra ID, Google Workspace, Keycloak	Salesforce, Workday, AWS, GitHub, Zendesk

One platform can play both roles. Microsoft Entra ID is usually the IdP, but it can also act as the SP to a third-party SAML 2.0 IdP that holds an on-premises directory, for Microsoft 365 sign-in. Microsoft only supports a limited set of clients in that setup, mainly web clients such as Outlook Web Access and SharePoint Online.

How does SAML IdP login work, step by step?

In the SP-initiated flow, the most common one, login takes six steps:

1. The user opens the app (SP) without an active session.
2. The SP creates an AuthnRequest with a unique ID and redirects the browser to the IdP’s SSO URL, usually over HTTP Redirect binding.
3. The IdP authenticates the user, or reuses an existing IdP session.
4. The IdP returns a signed SAML Response to the browser.
5. The browser POSTs the response to the SP’s ACS URL (HTTP POST binding).
6. The SP validates the response, creates a local session, and sends the user to the originally requested page (RelayState).

Microsoft documents this exact binding pattern for Microsoft Entra ID as a SAML IdP: Redirect for the request, POST for the response.

How is IdP-initiated SSO different?

In IdP-initiated SSO the user starts at the IdP portal (for example, the Okta dashboard) and clicks an app tile.

Factor	SP-initiated	IdP-initiated
AuthnRequest sent	Yes	No
Response tied to a request (InResponseTo)	Yes	No, the response is unsolicited
Replay protection	Request ID matching	SP must cache assertion IDs and enforce short validity windows
Typical use	SaaS apps, bookmarks, deep links	Internal portals, intranet dashboards
Supported in OIDC	Yes	No equivalent; OIDC flows always start from the app

Explore the topic: SAML vs SSO: Is SAML the Same as Single Sign-On?

What is the SAML IdP login URL?

The login URL is the SingleSignOnService location in the IdP’s metadata. Consoles label it differently: “SSO URL” in Google Workspace, “Login URL” in Microsoft Entra ID, and “Identity Provider Single Sign-On URL” in Okta. Users rarely visit it directly; the SP redirects them there.

What does a SAML identity provider example look like?

Below is a trimmed SAML Response from an IdP, with the fields the SP depends on marked in comments.

<samlp:Response ID="_resp789" InResponseTo="_req123"
    Destination="https://app.example.com/saml/acs"
    IssueInstant="2026-09-21T10:00:05Z">
  <saml:Issuer>https://idp.example.org/metadata</saml:Issuer>   <!-- who signed it -->
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:Assertion ID="_assert456" IssueInstant="2026-09-21T10:00:05Z">
    <ds:Signature>...</ds:Signature>                              <!-- IdP private-key signature -->
    <saml:Subject>
      <saml:NameID>jane.doe@example.org</saml:NameID>              <!-- the user -->
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2026-09-21T10:05:05Z"
            Recipient="https://app.example.com/saml/acs" InResponseTo="_req123"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2026-09-21T09:59:05Z" NotOnOrAfter="2026-09-21T10:05:05Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://app.example.com</saml:Audience>    <!-- intended SP -->
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AttributeStatement>
      <saml:Attribute Name="groups"><saml:AttributeValue>finance</saml:AttributeValue></saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Each field blocks a specific attack, but only if the SP checks it:

Field	What the SP must check	If the SP skips it
ds:Signature	The signature covers the exact assertion the SP reads	Signature wrapping: an unsigned assertion is injected beside a signed one
Issuer	Matches the trusted IdP’s entity ID	Assertions from a rogue IdP are accepted
Audience	Equals the SP’s own entity ID	An assertion issued for another app is replayed against yours
NotBefore / NotOnOrAfter	Current time is inside the window	Captured assertions are replayed later
InResponseTo	Matches the pending AuthnRequest ID	Unsolicited responses are injected
Recipient / Destination	Matches the SP’s ACS URL	Assertions are forwarded to the wrong endpoint

• Response vs assertion signing: an IdP can sign the whole Response, the Assertion inside it, or both. Google Workspace, for example, signs only the assertion unless the admin ticks “Signed response”. If your SP expects a signed Response, this default is a common cause of “signature missing” errors.

Continue reading: What Is a SAML Assertion? Structure, Example, and Validation (2026)

What does a real SAML IdP test run show?

We ran an SP-initiated login against Keycloak 26.7.4, the latest release as of September 28, 2026, to check how a real IdP behaves with default settings.

Test setup:

• Keycloak 26.7.4 in development mode on a local machine
• One realm (“demo”), one SAML client with entity ID https://app.example.com, and one user (jane.doe) in a “finance” group
• A minimal Python SP that sends an unsigned AuthnRequest, then verifies the returned signature with the signing certificate from the IdP’s metadata

Screenshot 1: the IdP metadata page

The metadata URL is /realms/{realm}/protocol/saml/descriptor. It lists everything an SP needs to trust the IdP.

File name: keycloak-saml-idp-metadata-screenshot.webp 

Screenshot 2: the decoded SAML Response

The SP decoded the Base64 SAMLResponse and ran eight checks. All eight passed, including signature verification.

What the test run found

Observation	Value in this run	What it means
Signatures	Response and Assertion both signed, RSA-SHA256 with SHA-256 digest	SPs that require either signature work without extra IdP changes
Assertion validity (Conditions)	60 seconds	SP and IdP clocks must agree within that window; use NTP on both
SubjectConfirmationData NotOnOrAfter	5 minutes after NotBefore	The browser POST must reach the ACS URL within 5 minutes
SessionNotOnOrAfter	10 hours	An SP session set longer than 10 hours outlives the IdP session
Unrequested attributes	6 Role attributes from Keycloak’s default role_list scope	Remove that scope from the client to send only what the app needs
Request signing	Metadata says WantAuthnRequestsSigned=”true”, yet the unsigned AuthnRequest was accepted	Metadata does not prove enforcement; check the client’s “Client signature required” setting

The last two rows are the practical lesson: default IdP settings can over-share attributes and silently accept unsigned requests, so review each SAML app’s settings instead of relying on metadata.

Which SAML IdP providers can you choose from in 2026?

This SAML identity providers list is grouped by deployment model, because hosting decides cost, control, and who patches the IdP.

Provider	Category	Hosting	Open source	Typical fit
Okta Workforce Identity	Cloud workforce IdP	SaaS	No	Mixed SaaS estates, large app catalogs
Microsoft Entra ID	Cloud workforce IdP	SaaS	No	Microsoft 365 organizations
Google Workspace	Cloud workforce IdP	SaaS	No	Google-first organizations
PingOne / PingFederate	Cloud and self-managed	SaaS or on-prem	No	Regulated enterprises, complex federation
OneLogin	Cloud workforce IdP	SaaS	No	Mid-market SSO
Cisco Duo	Cloud IdP or IdP proxy	SaaS	No	Adding MFA in front of an existing IdP
Microsoft AD FS	On-prem federation	Windows Server	No	Legacy Active Directory estates
Keycloak	Self-hosted IdP	Your infrastructure	Yes	Full control, no license cost
Shibboleth IdP	Self-hosted IdP	Your infrastructure	Yes	Higher-education and research federations
SimpleSAMLphp	Self-hosted IdP or SP	Your infrastructure	Yes	PHP environments, light federation
NetScaler ADC / Gateway	Network appliance IdP	Appliance or VPX	No	Sites already using NetScaler for remote access

For a neutral interoperability check, GitHub officially supports and internally tests six SAML IdPs: AD FS, Microsoft Entra ID, Okta, OneLogin, PingOne, and Shibboleth. Microsoft keeps a similar federation compatibility list for third-party IdPs used with Entra ID.

How do you choose a SAML IdP?

Your situation	Strongest starting option	Main trade-off
Already on Microsoft 365	Microsoft Entra ID	Advanced conditional access needs higher license tiers
Already on Google Workspace	Google Workspace	Fewer policy controls than dedicated IAM platforms
100+ SaaS apps from many vendors	Okta or Ping	Per-user subscription cost
Data must stay on your infrastructure	Keycloak or Shibboleth	You own patching, uptime, and scaling
University or research federation	Shibboleth	Steeper configuration learning curve
Need MFA in front of a legacy IdP	Duo as an IdP proxy	A second component to operate
NetScaler already handles remote access	NetScaler as IdP only with strict patching	Repeated 2026 CVEs in the SAML IdP role (see the Citrix section)

Five questions to settle before you buy or deploy:

1. Does the IdP support both SP- and IdP-initiated SSO for your apps?
2. Can it run two signing certificates at once for zero-downtime rotation?
3. Does it also provision users (SCIM), or only sign them in?
4. Can it encrypt assertions for SPs that require it, such as AWS IAM?
5. Who patches it, and how fast? For self-hosted and appliance IdPs, that is you.

What is a SAML IdP app, and how do you create one?

A SAML IdP app is the SP’s registration inside the IdP. It stores three things the IdP needs: the SP’s entity ID, its ACS URL, and the attributes to send.

IdP	What it calls the SAML app	Where the SP’s details go
Okta	SAML app integration	“Single sign-on URL” and “Audience URI (SP Entity ID)”
Microsoft Entra ID	Enterprise application (non-gallery)	“Reply URL (ACS URL)” and “Identifier (Entity ID)”
Google Workspace	Custom SAML app	“ACS URL” and “Entity ID”
Keycloak	Client, type SAML	“Client ID” (the SP entity ID) and “Valid redirect URIs”

Example: creating a custom SAML app in Google Workspace

Google Workspace has preintegrated SSO for over 200 cloud apps. For anything else, you add a custom SAML app:

1. In the Admin console, open Apps, then Web and mobile apps, then Add app, then Add custom SAML app. Super administrator rights are required.
2. Download the IdP metadata, or copy the SSO URL and Entity ID and download the certificate. Enter them in the SP’s SSO settings.
3. Enter the SP’s ACS URL (must start with https://), its Entity ID, and an optional Start URL, which sets RelayState.
4. Map attributes. Group membership can include up to 75 groups, and the response only lists groups the user belongs to.
5. Turn the app on for the right organizational units under User access.

In Keycloak, the same object is a client. In Keycloak 19 or later, you set the client type to SAML, use the SP’s entity URL as the Client ID, and turn on assertion signing.

How do you set up a SAML provider in AWS?

In AWS, the IdP connection is an IAM SAML identity provider: an IAM entity that describes your external IdP and serves as the principal in role trust policies. After creating it, you create one or more IAM roles that federated users assume (IAM SAML provider guide).

The IdP must send these attributes, with the names typed exactly (they are case-sensitive):

Attribute name	Required	Rule
https://aws.amazon.com/SAML/Attributes/Role	Yes	At least one comma-separated pair of role ARN and SAML provider ARN; several pairs make the user pick a role at console sign-in
https://aws.amazon.com/SAML/Attributes/RoleSessionName	Yes	2 to 64 characters, no spaces; use a user ID or email, not a display name
https://aws.amazon.com/SAML/Attributes/SessionDuration	No	900 to 43,200 seconds (15 minutes to 12 hours); the default is 1 hour
https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}	No	Passes session tags for attribute-based access control

Source: AWS SAML assertion requirements.

These rules cause most failed AWS setups:

Rule	Detail
Metadata file	UTF-8 without a byte order mark; the X.509 certificate needs a key of at least 1024 bits and no repeated extensions
Subject confirmation	Exactly one SubjectConfirmation element, with NotOnOrAfter and a Recipient that matches the AWS sign-in endpoint
Encrypted assertions	Supported by IAM since February 5, 2025 (AWS announcement). The ACS URL then changes to https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID, using the ID on the provider’s detail page
Encryption limits	IAM Identity Center and Amazon Cognito do not accept encrypted assertions from IAM SAML providers (AWS SAML 2.0 federation)
Key limit	A provider holds at most two private keys, which gives one rotation slot
Missing Role attribute	AWS returns “Response does not contain the required audience” (IAM SAML troubleshooting)

If you manage many AWS accounts, IAM Identity Center is AWS’s multi-account option. It accepts an external SAML IdP, but not encrypted assertions, so pick one approach per account set.

Is it safe to use Citrix NetScaler as a SAML IdP?

Only on a current build: NetScaler’s SAML IdP role has had two exploited memory-leak flaws in 2026, and both only affect appliances configured as a SAML IdP.

Disclosed	CVE	Severity	Status	Fixed builds (Citrix bulletin)
June 30, 2026	CVE-2026-8451	High	Exploited in the wild; alert issued by the Canadian Centre for Cyber Security	14.1-72.61, 13.1-63.18, and FIPS equivalents
March 23, 2026	CVE-2026-3055	Critical, CVSS v4.0 9.3	Exploited; listed in CISA’s Known Exploited Vulnerabilities catalog	14.1-60.58, 14.1-66.59, 13.1-62.23, 13.1-FIPS/NDcPP 13.1-37.262

Both flaws are pre-authentication memory overreads: a malformed SAML request makes the appliance return memory that can hold session tokens and credentials. FortiGuard sensors recorded more than 2,000 blocked CVE-2026-3055 attempts per day, peaking above 2,700, mainly against Germany, Hong Kong, France, the United States, and Poland.

Edge appliances are a growing target in general. In Verizon’s 2025 DBIR, edge devices and VPNs were 22% of vulnerability-exploitation targets, up from 3%, and only about 54% of those flaws were fully patched.

NetScaler SAML IdP checklist:

1. Search the configuration for add authentication samlIdPProfile. A match means the appliance is exposed to both CVEs.
2. Upgrade to 14.1-72.61 or 13.1-63.18 or later. These builds are past the fixes for both CVEs.
3. After patching, end active AAA sessions and rotate the SAML signing certificate, because leaked memory may have exposed tokens.
4. Citrix-managed cloud services and Citrix-managed Adaptive Authentication are patched by Citrix; the bulletins apply to customer-managed appliances only.

Find out more: What Is SAML Authentication? How It Works, With Examples

Which SAML IdP from GitHub or npm is safe for testing?

Use Keycloak for realistic tests and keep the lightweight Node and Docker IdPs strictly local: most “saml idp github” and “saml idp npm” results are unmaintained test tools.

Tool	Type	Status (checked September 2026)	Use it for
mcguinness/saml-idp (npm saml-idp)	Node.js test IdP	Last push July 25, 2023; 472 stars, 177 forks; depends on the legacy xmldom 0.1.x line	Local SP testing only
nccgroup/saml-idp	Fork of the above	README says it is not for production	Local SP testing only
kristophjunge/test-saml-idp	Docker, SimpleSAMLphp 1.15.2	Last updated about 8 years ago; ships static credentials and SSL keys	Avoid for new projects
samlify	npm library to build an IdP or SP	Versions before 2.10.0 have CVE-2025-47949, a signature wrapping flaw	Production code, pinned to 2.10.0 or later
Keycloak	Full open-source IdP	Actively released	Integration and staging tests

The mcguinness tool’s own author describes it as a simulator that is “insecure by design”: it mints whatever assertion you type, with no real authentication.

Three rules for test IdPs:

1. Never let a production SP trust a test IdP’s certificate. Anyone running the tool can mint an assertion for any user.
2. Generate a fresh key pair. Public forks of these repos commit their idp-private-key.pem files, so reused keys are effectively public.
3. Never expose a test IdP to the internet; bind it to localhost or a private network.

Which SAML vulnerabilities hit IdPs and SPs in 2025 and 2026?

Most SAML library flaws of the past two years share one root cause: the code verifies the signature on one XML element but reads the user’s identity from another. The NetScaler IdP flaws are covered in the Citrix section above.

Date	Component	CVE	Impact	Fixed in
Dec 2025	php-saml, xmlseclibs	Research disclosure	Vulnerable to a canonicalization exploit; the XMLSec Library and Shibboleth xmlsectool were not	Vendor-specific
Dec 2025	ruby-saml (SP library)	CVE-2025-66567, CVE-2025-66568	Authentication bypass up to 1.12.4, from an incomplete earlier fix	1.18.0
2025	samlify (Node.js)	CVE-2025-47949	Signature wrapping (see the test IdP table)	2.10.0
Mar 2025	ruby-saml	CVE-2025-25291, CVE-2025-25292	One valid signature from the target’s key let an attacker forge assertions and log in as any user	1.12.4 or 1.18.0

Attackers do not always need to intercept a login. PortSwigger found that valid IdP-signed XML documents are often publicly available and can be repurposed for these attacks.

Hardening steps for SAML libraries:

• Put SAML libraries under automated dependency alerts and patch them as fast as the login page itself.
• Reject any response containing more than one assertion.
• Read identity only from the element the verified signature references.
• Prefer libraries built on the XMLSec Library or on implementations not affected by the research above.
• Re-test after upgrades: ruby-saml’s December 2025 CVEs came from an incomplete fix for the March 2025 ones.

SAML vs OAuth vs OIDC: which one does your app need?

SAML and OIDC are sign-in (authentication) protocols; OAuth 2.0 on its own is not. It grants an app access to an API on a user’s behalf.

Factor	SAML 2.0	OAuth 2.0	OpenID Connect (OIDC)
Purpose	Authentication and federation	Delegated authorization	Authentication built on OAuth 2.0
Token	Signed XML assertion	Access token (format not fixed)	ID token (JWT) plus access token
Uses an “IdP”	Yes	No (uses an authorization server)	Yes (the OpenID Provider)
IdP-initiated login	Yes	Not applicable	No
Best fit	Enterprise web SSO, B2B federation	API access for apps and agents	Modern web, mobile, and single-page app login
Mobile and API fit	Low	High	High

NIST SP 800-63C-4 treats the two sign-in protocols as equivalent federation options, naming both the OIDC ID token and the SAML assertion as example assertions. Many organizations run SAML for established enterprise apps and OIDC for newer ones, often from the same IdP.

Learn more here: SAML vs OAuth: What Is the Difference and Which Should You Use in 2026?

How do you fix the most common SAML IdP errors?

Decode the SAML Response first (browser developer tools or a SAML tracer extension), then match the symptom:

Symptom	Likely cause	Fix
“Invalid signature” after months of working SSO	IdP signing certificate rotated or expired	Re-import IdP metadata; run old and new certificates side by side during rotation
“Signature missing”	SP expects a signed Response, IdP signs only the Assertion	Turn on Response signing in the IdP, or relax the SP setting
“Assertion expired” or “not yet valid”	Clock drift between IdP and SP servers	Sync both with NTP; keep the SP’s skew tolerance to a few minutes
“Audience mismatch”	SP entity ID typed wrong in the IdP app	Copy the entity ID exactly from the SP’s metadata
Login works, but roles or groups are missing	Attribute names differ (for example mail vs email)	Align attribute names with the SP’s documentation
“InResponseTo mismatch”	IdP-initiated response sent to an SP-initiated-only app, or a stale request	Enable IdP-initiated support on the SP, or start login from the SP

How do you rotate a SAML signing certificate without an outage?

Microsoft Entra ID shows the pattern clearly (Microsoft certificate management tutorial):

• New signing certificates default to a 3-year lifetime.
• Entra ID emails expiry warnings 60, 30, and 7 days ahead, to up to five addresses; add a team distribution list.
• Create the new certificate with an overlapping date, upload it to the SP, then activate it.
• An SP that never checks certificate expiry keeps accepting an expired certificate. This hides the problem until the IdP switches certificates and logins suddenly fail.

Frequently Asked Questions (FAQs)

Is Okta a SAML IdP?

Yes. Okta acts as a SAML IdP for thousands of apps, and it can also act as an SP when federating to another organization’s IdP.

Is SAML still used in 2026?

Yes. AWS added encrypted-assertion support to IAM in 2025, and GitHub, Microsoft 365, and Google Workspace all support SAML SSO. New cloud-native apps often default to OIDC, so most organizations run both.

Where do I find my IdP’s SAML metadata URL?

• Keycloak: https://<host>/realms/<realm>/protocol/saml/descriptor
• Microsoft Entra ID: “App Federation Metadata Url” in the app’s SAML single sign-on settings
• Google Workspace: “Download IdP metadata” when creating the custom SAML app
• Okta: “Metadata URL” on the app’s Sign On tab

Do SAML assertions need to be encrypted?

Signing is mandatory; encryption is optional. Encryption hides assertion contents from the browser and is worth enabling when assertions carry sensitive attributes, and the SP supports it.

How long does a SAML session last?

The SP decides, not the assertion. GitHub Enterprise Server, for example, keeps a SAML session active for 24 hours before sending the user back to the IdP, and AWS console sessions last 15 minutes to 12 hours depending on the SessionDuration attribute.