Skip to demo content

SP-Initiated SAML with Okta

OTS authenticates directly with Okta via SAML 2.0

This is a static, self-contained demo for educational purposes. It does not connect to any live systems and is not intended as a reference implementation.

Step 1 of 7: User requests protected resource
Keyboard:
←→ Navigate Space Autoplay R Restart 123 Speed T Transcript
1

User requests protected resource

User navigates to the OTS dashboard. OTS checks for a valid session and finds none, so it generates a SAML AuthnRequest with a unique ID and redirects the browser to Okta.

SP-initiated SAML requires the SP to generate a fresh AuthnRequest with a unique ID for each login attempt. The ID must be stored server-side and later matched against InResponseTo in the SAML Response, preventing unsolicited response injection. The RelayState parameter preserves the deep link so the user lands on the correct page after authentication.

What the user sees

https://secrets.example.com/dashboard
Demo simulation — do not enter real credentials
Redirecting to login...

What's happening (HTTP)

REQUEST Browser → OTS
GET https://secrets.example.com/dashboard
Cookie: (none)
💡 No session cookie present
INTERNAL OTS → OTS
Session check + AuthnRequest generation
💡 No valid session found. Generate AuthnRequest with unique ID (_request_abc123), store ID for InResponseTo validation, set RelayState to /dashboard.
RESPONSE OTS → Browser
302 Found
Location: https://contoso.okta.com/app/ots-saml/exk1234/sso/saml?
SAMLRequest=base64-deflate-encoded-xml
&RelayState=%2Fdashboard
&SigAlg=http://www.w3.org/2001/04/xmldsig-more%23rsa-sha256
&Signature=base64-encoded-signature
💡 HTTP-Redirect binding: AuthnRequest is deflated, base64-encoded, and URL-encoded. Signature covers SAMLRequest + RelayState + SigAlg concatenated.

Legend

Browser request
Server response
Server-to-server
Internal process

Protocol Stack

🔐
OTS
Service Provider
SAML
🔑
Okta
Identity Provider
← All demos
An Authentication Flow Demo v0.1.0