SAML vs OIDC Decision and Spring Security saml2 RelyingPartyRegistration
Fast recall
Quick revision
Core answer
Whether the candidate can both reason about protocol choice and walk through the SP-side wiring in Spring Security 6.
Treating SAML as legacy and ignoring it; or wiring SAML without understanding RelyingPartyRegistration, ACS URL, or signature verification.
Discuss DB-backed RelyingPartyRegistrationRepository for multi-tenant, encrypted assertions, NameID format selection, and the OpenSAML4 customization hook.
Interview-ready guide
Interview answer
Decision rule
- OIDC for new integrations: modern JSON, PKCE, mobile-friendly
- SAML when customer mandates it (enterprise, gov, healthcare)
- B2B SaaS: support both; OIDC primary, SAML fallback
SAML in Spring 6: starter and DSL
spring-security-saml2-service-providerhttp.saml2Login()+saml2Logout()+saml2Metadata()
RelyingPartyRegistration anatomy
registrationId— opaque ID in URLsentityId— SP's SAML identity- ACS URL —
/login/saml2/sso/{registrationId}where IdP POSTs response - SLO URL —
/logout/saml2/slo - SP signing + decryption keys
- AssertingPartyDetails from IdP metadata
Property-driven config
spring.security.saml2.relyingparty.registration.withassertingparty.metadata-uri- Spring auto-creates
RelyingPartyRegistrationRepository - SP metadata XML at
/saml2/service-provider-metadata/{id}
Auto endpoints
GET /saml2/authenticate/{id}initiates SP-initiated SSOPOST /login/saml2/sso/{id}is the ACSPOST /logout/saml2/slofor SLO
Custom attribute -> authority
OpenSaml4AuthenticationProvider.setResponseAuthenticationConverter- Read
groupsattribute, map toROLE_*
Multi-tenant
- Custom
RelyingPartyRegistrationRepositoryreading from DB - Resolve tenant from subdomain or email domain
- Cache registrations; invalidate on config changes
Production care
- Cert rotation via
metadata-uri; multiple verification credentials during overlap - Federated ID
(issuer, NameID)as user primary key, not email SameSite=Laxfor callback POST- Encrypted assertions for sensitive data
- IdP cert expiry alerting
SAML vs OIDC Decision and Spring Security saml2 RelyingPartyRegistration
Direct Answer
Decision rule: prefer OIDC for new integrations (modern JSON, PKCE, mobile/SPA support); choose SAML when the customer's IdP only speaks SAML or compliance/procurement mandates it. In Spring Security 6, SAML 2.0 SP support is built into spring-security-saml2-service-provider and centers on RelyingPartyRegistration — it holds the SP entity ID, the ACS (assertion consumer) and SLO URLs, the SP signing/decryption keys, and the AssertingPartyDetails (IdP entity ID, SSO/SLO URLs, verification certs). You enable it with http.saml2Login() and http.saml2Logout(), store registrations in a RelyingPartyRegistrationRepository (in-memory or DB-backed for multi-tenant), and customize attribute-to-authority mapping via OpenSaml4AuthenticationProvider.setResponseAuthenticationConverter.
Common Mistakes & Pitfalls
Treating SAML as legacy and ignoring it; or wiring SAML without understanding RelyingPartyRegistration, ACS URL, or signature verification.
Check your understanding
Answer these without looking back at the article.
- When would you choose SAML over OIDC for a new integration?
- How do you store and resolve RelyingPartyRegistration for hundreds of tenants?
- How do encrypted SAML assertions work and when do you need them?
- What is the difference between SP-initiated and IdP-initiated SSO?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.