How do I add SAML login to an existing app?

To add SAML login to an existing app, the usual approach is to make your app act as a SAML Service Provider (SP) and integrate with your customer’s Identity Provider (IdP) like Okta, Azure AD, Ping, OneLogin, etc.

High-level steps

1. Pick a SAML library / middleware

   • Use a proven SAML toolkit for your stack rather than building SAML yourself.
   • Examples:
     • Node.js: passport-saml, samlify
     • Python: python3-saml, pysaml2
     • Java: Spring Security SAML / OpenSAML
     • Ruby: ruby-saml
     • .NET: Sustainsys.Saml2

2. Add SP endpoints to your app You typically need:

   • ACS endpoint (Assertion Consumer Service): where the IdP sends the SAML response, e.g. /auth/saml/acs
   • Login/initiation endpoint: starts SSO, e.g. /auth/saml/login
   • Optional:
     • /auth/saml/metadata to expose your SP metadata
     • /auth/saml/logout for SLO, if you support it

3. Configure your app as an SP You’ll need values like:

   • Entity ID (your app’s unique SAML identifier)
   • ACS URL
   • Certificate for signing/verifying (often public cert for IdP config, private key if you sign requests)
   • IdP-provided:
     • IdP Entity ID
     • SSO URL
     • IdP certificate

4. Implement the SSO flow Typical flow:

   • User clicks “Sign in with SSO”
   • Your app redirects them to the IdP
   • IdP authenticates user
   • IdP POSTs a SAML Response to your ACS endpoint
   • Your app validates:
     • signature
     • issuer
     • audience
     • destination
     • timestamps / replay protection
   • Your app creates a local session and logs the user in

5. Map SAML attributes to your user model Common attributes:

   • email
   • name
   • first_name
   • last_name
   • groups
   • role

   Decide how to:

   • find existing users
   • create new users on first login
   • link SAML identity to local accounts

6. Add tenant / organization configuration If your app supports multiple customers, store per-tenant SAML settings:

   • IdP Entity ID
   • SSO URL
   • x509 certificate
   • enabled flag
   • required domain(s)
   • attribute mappings

7. Test with a real IdP Use a dev IdP like:

   • Okta developer org
   • Azure AD test tenant
   • OneLogin sandbox
   • SimpleSAMLphp for local testing

---

Important security checks

When validating SAML assertions, make sure to verify:

• Signature is valid
• Assertion is intended for your SP (AudienceRestriction)
• Response is for your ACS URL (Destination / Recipient)
• Assertion is not expired (NotBefore, NotOnOrAfter)
• InResponseTo matches a request you initiated, if using SP-initiated login
• Prevent replay attacks
• Use HTTPS everywhere

---

Recommended implementation pattern

For most apps, the easiest path is:

• SP-initiated login
• One ACS endpoint
• One metadata endpoint
• Per-organization IdP config
• Just-in-time user provisioning on first login

This keeps the user experience simple and is common in B2B SaaS.

---

Example flow for a SaaS app

1. Admin enters IdP details in your app:
   • SSO URL
   • Issuer
   • Certificate
2. Your app generates SP metadata
3. Customer uploads metadata to their IdP
4. User visits your app
5. Your app redirects to IdP
6. IdP returns signed SAML assertion
7. You verify it, find/create user, start session

---

Things to watch out for

• SAML is usually enterprise-only; many consumer apps use OAuth/OIDC instead.
• Handling logout across SAML apps can be tricky.
• Cert rotation must be supported.
• Multi-tenant SAML config needs good admin UX.
• Be clear about whether you use:
  • email as identifier
  • NameID
  • a custom attribute like uid

---

If you want the simplest answer

If your app already has normal username/password login, add SAML by:

• choosing a SAML SP library
• adding /saml/login and /saml/acs
• validating assertions
• mapping the SAML user to your internal user
• creating a session after successful validation

If you tell me your stack (Node, Python, Java, .NET, etc.) and whether you want Okta/Azure AD support, I can give you a concrete implementation example.