SAML Authentication in Python — Core Concepts

What SAML solves

Enterprises run dozens of internal applications. Without SAML, each app maintains its own user database and login form. Employees manage separate credentials everywhere, IT has no central way to disable access, and password fatigue leads to weak passwords.

SAML (Security Assertion Markup Language) 2.0 solves this with federated authentication. One trusted system — the Identity Provider (IdP) — handles all authentication. Applications — called Service Providers (SPs) — accept signed assertions from the IdP instead of managing passwords themselves.

The three actors

Identity Provider (IdP) — the central login authority. Examples: Okta, Azure AD, OneLogin. It authenticates users and issues SAML assertions.

Service Provider (SP) — your application. It needs to know who the user is but doesn’t handle login directly.

User (Principal) — the person trying to access the SP. They interact with both but only type their password at the IdP.

The SP-initiated flow

This is the most common pattern:

1. User visits your Python app (the SP)
2. App sees no active session, generates a SAML AuthnRequest
3. User’s browser gets redirected to the IdP with that request
4. IdP prompts for login (or skips if already logged in — that’s the SSO part)
5. IdP creates a SAML Response containing an Assertion with user attributes
6. Browser POSTs that response back to your app’s Assertion Consumer Service (ACS) URL
7. App validates the signature, extracts user info, creates a session

What’s inside a SAML Assertion

The assertion is an XML document containing:

NameID — the user’s identifier (email, employee ID, or opaque identifier).

Attributes — additional data like name, groups, roles, or department. What gets sent is configured at the IdP.

Conditions — time window during which the assertion is valid. Prevents replay attacks with stale assertions.

AuthnStatement — how and when the user authenticated (password, MFA, etc.).

Python integration with python3-saml

The python3-saml library from OneLogin is the most widely used Python SAML toolkit. You configure it with two JSON files: one describing your SP (entity ID, ACS URL, certificate) and one describing the IdP (entity ID, SSO URL, certificate).

Your app needs two endpoints: one to initiate login (builds the AuthnRequest and redirects) and one ACS endpoint to receive the response. The library handles XML parsing, signature validation, and attribute extraction.

Metadata exchange

Rather than manually configuring URLs and certificates, SAML uses metadata XML documents. The IdP publishes its metadata (SSO endpoints, signing certificates), and your SP publishes its metadata (ACS URL, entity ID). Importing metadata reduces configuration errors and makes certificate rotation smoother.

Common misconception

“SAML and OAuth/OIDC do the same thing.” They overlap but serve different worlds. SAML dominates enterprise SSO — it’s XML-based, mature, and deeply integrated into corporate identity systems. OAuth 2.0 and OpenID Connect are lighter, JSON-based, and dominate consumer and API scenarios. Many organizations use both: SAML for internal apps, OIDC for external or mobile apps.

The one thing to remember: SAML lets your Python app outsource login to a trusted identity provider, receiving a cryptographically signed XML assertion that proves who the user is — no password handling required on your end.