PRD Template for SSO
A complete product requirements template for building single sign-on. Pre-filled with examples for SAML 2.0, OIDC, IdP configuration, just-in-time provisioning, and enterprise security compliance.
What makes SSO PRDs different
SSO is one of the few features that is a binary gate for enterprise sales. Companies do not negotiate on SSO — if you do not have it, you do not pass the security review, and the deal does not close. This makes SSO a revenue feature, not a security feature, even though it provides significant security benefits.
The technical challenge is that SAML and OIDC are protocol-level specifications with significant implementation complexity. SAML involves XML parsing, certificate management, and assertion validation. OIDC involves token exchange flows, JWKS endpoints, and scope management. Each identity provider (Okta, Azure AD, Google Workspace) has its own quirks and configuration requirements.
The template below covers the business case (deals blocked, revenue at risk), the protocol requirements (SAML 2.0, OIDC), and the practical considerations (IdP configuration, testing, lockout recovery) that make SSO implementable and enterprise-ready.
SSO PRD template
Eight sections covering every aspect of single sign-on.
Problem Statement
SSO is the top enterprise security requirement. Companies with 100+ employees mandate that all SaaS tools authenticate through their identity provider (Okta, Azure AD, Google Workspace). Without SSO, your product cannot be adopted by these organizations — it is a binary gate, not a nice-to-have.
Example: "We have lost or stalled 7 enterprise deals totaling $480K ARR in the past year because we do not support SSO. In each case, the company security review required SAML-based SSO as a non-negotiable prerequisite. Additionally, our product's independent password management creates a security gap for existing enterprise users — if an employee leaves, their access to our product persists until we are manually notified. 3 customers have reported security concerns about former employees retaining access."
Tips
- Count enterprise deals lost or stalled due to missing SSO
- Identify which identity providers your target customers use (Okta, Azure AD, Google)
- Document security risks from independent password management (deprovisioning gaps)
- Assess competitor SSO support — most mature B2B products offer it
Goals and Objectives
SSO goals must address enterprise sales enablement, security improvement, and user experience. SSO should make authentication easier for enterprise users while giving IT admins the control they need.
Example: "Primary: Support SAML 2.0 and OIDC SSO to unblock enterprise deals requiring centralized authentication. Sales: Close 3+ enterprise deals ($150K+ ARR) that are currently blocked by missing SSO within 6 months of launch. Security: Automatic deprovisioning — when a user is removed from the IdP, their access is revoked within 1 hour. UX: Enterprise users sign in with one click through their corporate identity provider."
Tips
- Set a revenue target for deals unblocked by SSO
- Include automatic deprovisioning as a security goal
- Define which protocols to support: SAML 2.0 is required, OIDC is increasingly preferred
- Set an implementation timeline — enterprise deals cannot wait for an extended roadmap
User Stories
SSO user stories span the end user (who logs in), the IT admin (who configures the IdP connection), and the account admin (who enables SSO for their organization).
Example: "As an IT administrator, I want to configure SAML SSO for my organization so that employees authenticate through our corporate identity provider (Okta) instead of creating separate passwords. Acceptance criteria: I can upload the IdP metadata XML or enter the SSO URL, entity ID, and certificate manually; I can test the connection before enforcing it; once enabled, all users in the organization must use SSO to log in; I can enforce SSO login (disable password login) for the entire organization."
Tips
- Write stories for the IT admin configuring SSO, the user logging in via SSO, and the account admin enabling SSO
- Include a story for just-in-time provisioning: auto-creating accounts when users sign in for the first time
- Cover the enforcement story: what happens when SSO is required but a user tries to use password login
- Add a story for deprovisioning: revoking access when a user is removed from the IdP
Functional Requirements
SSO requirements must specify supported protocols, IdP configuration, user provisioning, enforcement options, and fallback mechanisms. Enterprise IT teams expect a standard SSO implementation with no surprises.
Example: "FR-1: The system must support SAML 2.0 SP-initiated and IdP-initiated SSO. FR-2: The system must support OIDC-based SSO (authorization code flow). FR-3: Admin must be able to configure SSO via metadata upload or manual entry (SSO URL, Entity ID, X.509 certificate). FR-4: Just-in-time provisioning must auto-create user accounts on first SSO login, assigning a default role. FR-5: Admins must be able to enforce SSO (disable password login) for their organization. FR-6: A recovery mechanism must exist for admins locked out of SSO (admin bypass link, valid 24h)."
Tips
- Support both SAML 2.0 and OIDC — different enterprises use different protocols
- Include just-in-time provisioning to avoid manual user creation
- Define SSO enforcement: the ability to require SSO and disable other login methods
- Include a recovery mechanism in case the IdP is misconfigured or down
Non-Functional Requirements
SSO must be highly available — if SSO is down and enforced, no one in the organization can log in. Latency in SSO affects the login experience for every enterprise user.
Example: "NFR-1: SSO authentication must complete within 3 seconds (redirect to IdP, authentication, and redirect back). NFR-2: SSO endpoints must maintain 99.99% uptime — SSO downtime blocks all users in enforced organizations. NFR-3: SAML assertions must be validated against the registered X.509 certificate. NFR-4: The system must support multiple concurrent SSO configurations (for organizations with multiple IdPs). NFR-5: SSO session tokens must respect the IdP session lifetime — when the IdP session expires, re-authentication is required."
Tips
- Set high availability targets for SSO — downtime blocks all enterprise users
- Define SSO latency targets including the IdP round-trip
- Require certificate validation for SAML assertions
- Support IdP session management: respect IdP session expiry and global logout
Success Metrics
SSO success is measured by enterprise deal conversion, security improvement, and user adoption.
Example: "Metric 1: Enterprise deals closed with SSO as a factor. Target: 3+ deals, $150K+ ARR within 6 months. Metric 2: SSO adoption among enterprise customers. Target: 90% of enterprise orgs (50+ users) configure SSO within 60 days. Metric 3: Time to configure SSO. Target: under 30 minutes. Metric 4: Access revocation time after IdP deprovisioning. Target: under 1 hour. Metric 5: SSO-related support tickets. Target: under 5/month."
Tips
- Track SSO-influenced revenue as the primary business metric
- Measure time to configure SSO as a usability metric
- Monitor deprovisioning latency as a security metric
- Track SSO-related support tickets for quality
Technical Considerations
SSO implementation involves SAML XML parsing, certificate management, session synchronization with the IdP, and SCIM for user provisioning. Using an SSO middleware library (like WorkOS, Auth0, or BoxyHQ) significantly reduces implementation complexity.
Example: "We will use WorkOS as the SSO middleware to handle SAML and OIDC protocol complexity, certificate management, and IdP metadata parsing. Our application receives a normalized user profile from WorkOS regardless of the IdP or protocol used. Just-in-time provisioning creates a user record and assigns them to the organization based on the email domain. SCIM 2.0 support (via WorkOS) enables automatic user provisioning and deprovisioning from the IdP directory. We will support the top 5 IdPs: Okta, Azure AD, Google Workspace, OneLogin, and JumpCloud."
Tips
- Use an SSO middleware (WorkOS, Auth0) to avoid implementing SAML/OIDC from scratch
- Support SCIM 2.0 for automated user provisioning and deprovisioning
- Test with the top 5 identity providers — each has quirks
- Store IdP certificates securely and support certificate rotation
Risks and Mitigations
SSO risks include lockout (misconfiguration blocks all users), IdP dependency (IdP outage affects your product), and security gaps (improperly validated SAML assertions).
Example: "Risk: Admin misconfigures SSO, locking out their entire organization. Likelihood: Medium. Impact: Critical (all users blocked). Mitigation: SSO test mode — admins test the connection before enforcing it. Admin bypass link (emailed to account owner) valid for 24 hours. Risk: IdP outage blocks enterprise users from logging in. Likelihood: Low. Impact: High. Mitigation: Cache valid SSO sessions for up to 24 hours. Alert affected organizations about IdP connectivity issues."
Tips
- Implement SSO test mode so admins can verify before enforcement
- Include an admin bypass mechanism for lockout recovery
- Consider caching SSO sessions to survive brief IdP outages
- Validate SAML assertions thoroughly — improperly validated assertions are a critical security vulnerability
Related templates
Frequently asked questions
Generate your SSO PRD from real data
Connect your sales pipeline and codebase. Vantage generates an SSO PRD with actual deal data and requirements mapped to your auth architecture.
Free to start. No credit card required.