When a company asks for single sign-on on its Magento store, the first technical question is usually which protocol to use. SAML 2.0 and OpenID Connect (OIDC) solve the same problem: the store trusts an identity provider such as Microsoft Entra ID, Okta, Keycloak or Auth0 to say who the user is. They do it differently, and the differences matter for setup, maintenance and the kind of storefront you run.
Short answer: use OpenID Connect when your identity provider offers it, and SAML when the identity team requires it or the provider only speaks SAML. The rest of this article explains why.
How each protocol works
SAML 2.0
SAML is the older standard, from 2005, and it is still the default in many enterprises. The store is a service provider and the identity provider sends it a signed XML document, the assertion, through the user’s browser. The assertion says who the user is and carries attributes such as email, name and groups.
Setup revolves around metadata. The store publishes its metadata: its entity ID, the Assertion Consumer Service (ACS) URL that receives assertions, and optionally a certificate. The identity provider publishes its own metadata: its entity ID, sign-in URL and signing certificate. Each side imports the other’s.
OpenID Connect
OIDC is an identity layer on top of OAuth 2.0, from 2014. The user signs in at the provider, which redirects back to the store with a short-lived authorization code. The store exchanges that code directly with the provider for an ID token, a signed JSON Web Token (JWT) with the user’s claims.
Setup revolves around discovery. The store only needs the provider’s issuer URL, a client ID, a client secret and a registered redirect URI. Everything else, including signing keys, is fetched from the provider’s discovery document, and keys rotate without anybody touching the store.
Side-by-side
| SAML 2.0 | OpenID Connect | |
|---|---|---|
| Format | Signed XML assertions | Signed JSON Web Tokens |
| Delivery | Through the browser (HTTP POST) | Code through the browser, token server-to-server |
| Setup | Exchange metadata and certificates | Issuer URL, client ID, secret, redirect URI |
| Key rotation | Certificate renewal, often manual | Automatic through discovery |
| Typical home | Enterprise IdPs, older systems, B2B partners | Modern IdPs, cloud apps, mobile and SPA |
| Main risks | XML signature handling, replay | State and nonce handling, token validation |
What a Magento store needs to get right
Whichever protocol you choose, the security of SSO depends on the service provider, which here is the Magento extension. Before you trust an SSO module with customer or admin accounts, check what it validates.
For OpenID Connect, the module should validate the ID token signature, issuer and audience, and use a nonce and a browser-bound state value to stop replayed or injected responses. It should also use PKCE (S256) when the provider supports it.
For SAML, the module should validate signatures, correlate each response with the request that started it, check the assertion’s audience and validity window, and reject a replayed assertion.
IdPlug Customer SSO does all of the above for both protocols, and its authentication logs never store raw assertions, ID tokens, authorization codes or client secrets.
Account matching matters just as much. A module that signs people in by email address alone can be tricked by anyone who can change an email address at the provider. IdPlug matches an existing customer by email only once, then stores a persistent link to the provider’s stable subject and uses that link from then on.
When to choose OpenID Connect
- Your provider is Microsoft Entra ID, Okta, Auth0 or Keycloak. All of them support OIDC well, and setup is a few fields instead of a metadata exchange.
- You don’t want certificate renewals in your calendar. Signing keys come from discovery.
- You run a headless or PWA storefront. OIDC’s redirect-and-code model fits single-page and mobile clients naturally. In IdPlug, headless sign-in finishes with a one-time code that the frontend exchanges for a Magento customer token over REST or GraphQL, so the token never appears in a URL. That exchange is part of IdPlug Admin SSO.
When to choose SAML
- The identity team has standardized on SAML and provisions every enterprise application that way.
- The provider only speaks SAML, as some older or on-premises identity systems do.
- A B2B customer brings its own identity provider and prefers SAML for partner federation. With several providers per website, which IdPlug Admin SSO allows, each customer company can use the protocol it prefers.
Customer SSO and admin SSO don’t have to match
Storefront customers and Magento administrators can use different providers and different protocols. A common setup is OIDC with Entra ID for staff in the admin, and a separate customer identity service, or a B2B customer’s own SAML provider, for the storefront. In IdPlug each identity provider record says whether it applies to the storefront, the admin or both.
Try it before you decide
Protocol debates end quickly once you can see a real sign-in. IdPlug’s Test Sign-in runs one real sign-in from the provider screen, even before the provider is enabled. It shows the attributes the provider sent, how they map, and what a real sign-in would do, without signing anybody in or creating any account. Try it with both protocols if your provider supports both, and keep the one that gives you clean claims with less configuration.
For a concrete walkthrough, read how to set up Microsoft Entra ID single sign-on for Magento 2. Customer SSO is free; see the IdPlug suite overview to compare it with the paid modules.