OpenBOM SSO
An Administrator’s Guideline for Configuring Single Sign On (SSO) for OpenBOM
Overview
OpenBOM supports enterprise Single Sign-On (SSO) for company subscriptions. SSO allows your team to sign in to OpenBOM using your organization’s existing identity provider, so access to OpenBOM is governed by your corporate security policies rather than by individually managed passwords.
This page explains how OpenBOM SSO works, the security architecture behind it, and the steps required to enable and configure SSO for your company. It is written for IT administrators and security teams who need to confirm that OpenBOM meets their organization’s authentication and access control requirements.
- Overview
- How OpenBOM SSO Works
- Supported Identity Providers and Protocols
- Security Architecture
- Enabling SSO for Your Company
- Questions from IT and Security Teams
- Getting Help
Summary for security reviewers: OpenBOM delegates authentication to your identity provider through WorkOS, a SOC 2 Type II certified enterprise authentication platform. OpenBOM does not receive, process, or store corporate passwords. Organization membership is invite-only, and just-in-time provisioning is disabled by default, so a successful authentication alone never creates access to your company data.
How OpenBOM SSO Works
OpenBOM SSO is built on WorkOS, an enterprise authentication platform used by a broad base of B2B software companies. WorkOS acts as the connection layer between OpenBOM and your identity provider. When SSO is enabled for your company, the sign-in sequence is as follows.
- A user navigates to OpenBOM and initiates sign-in with their corporate email address.
- OpenBOM redirects the user to your identity provider through WorkOS.
- Your identity provider authenticates the user according to your corporate policies, including multi-factor authentication, conditional access, and device compliance rules where you enforce them.
- On successful authentication, the user is returned to OpenBOM with a signed identity assertion.
- OpenBOM matches the asserted identity to an existing account in your organization and establishes the session.
At no point does OpenBOM see, store, or process your users’ corporate passwords. Authentication happens entirely within your identity provider, and OpenBOM receives only the verified identity assertion.
Supported Identity Providers and Protocols
OpenBOM SSO supports the industry standard protocols SAML 2.0 and OpenID Connect (OIDC). This means it works with all major enterprise identity providers.
| Identity provider | Protocol |
|---|---|
| Microsoft Entra ID (Azure AD) | SAML 2.0 / OIDC |
| Okta | SAML 2.0 / OIDC |
| Google Workspace | SAML 2.0 / OIDC |
| OneLogin | SAML 2.0 |
| Ping Identity | SAML 2.0 |
| JumpCloud | SAML 2.0 |
| Any standards compliant provider | SAML 2.0 / OIDC |
Configuration is performed through a guided self-service portal. Your IT team connects OpenBOM to your identity provider directly, using your own credentials and settings. OpenBOM never requires administrative access to your identity provider.
Security Architecture
Authentication Is Delegated, Not Duplicated
OpenBOM does not maintain a parallel credential store for SSO users. Your identity provider remains the single point of authentication. This means your existing controls apply to OpenBOM access automatically, with no separate configuration inside OpenBOM.
- Password complexity, rotation, and reuse policies
- Multi-factor authentication enforcement
- Conditional access and device compliance rules
- Session lifetime and re-authentication requirements
- Immediate revocation of access on deactivation
Built on a SOC 2 Type II Certified Platform
The WorkOS authentication platform that powers OpenBOM SSO is SOC 2 Type II certified and compliant with GDPR and CCPA. WorkOS undergoes annual third party penetration testing and external code audits. The identity data stored by the platform is limited to the attributes sent from your identity provider, typically name and email address. Credentials are not stored. Compliance documentation is published at workos.com/security.
Invite-Only Membership by Design
OpenBOM company organizations are configured with controlled membership. Two properties of that configuration are important for access control review.
- No automatic membership. Holding an email address on your corporate domain does not grant access to your OpenBOM organization. Every user account must be explicitly created by your OpenBOM administrator.
- Just-in-time provisioning is disabled by default. A successful SSO authentication does not create a new OpenBOM account. Users must be provisioned before they can access your company’s product data.
The practical effect is that your OpenBOM administrator retains full control over who has access to your organization’s data, independently of the contents of your identity provider directory.
Flexible Authentication Policy
Your company’s domain policy in OpenBOM can be configured to match your security requirements.
| Policy | Behavior | Typical use |
|---|---|---|
| SSO only | All users on your corporate domain must authenticate through your identity provider. Password sign-in is rejected. | Steady state for enterprise deployments |
| SSO and email + password | Both methods are accepted for users on your domain. | Rollout period, or accounts outside the identity provider such as external contractors |
Most enterprise customers move to SSO only enforcement once the initial rollout has been verified.
Enabling SSO for Your Company
SSO is available for OpenBOM company subscriptions. Setup is a short sequence of steps shared between your team and OpenBOM.
Step 1: Prepare Your OpenBOM Organization
Your company subscription must be provisioned with at least one Owner and one Admin. Your administrator then creates OpenBOM accounts for all users who will access the system. This is required because OpenBOM uses invite-only membership: SSO authenticates users, but accounts must exist before those users can sign in.
Step 2: Request SSO Activation
Contact OpenBOM support at support@openbom.com to request SSO for your company. The OpenBOM team enables SSO for your organization and registers your corporate email domain. You will receive a configuration link and setup details.
Step 3: Configure Your Identity Provider Connection
Using the configuration link, your IT administrator connects OpenBOM to your identity provider through the guided setup portal. The portal provides instructions specific to your identity provider, including the SAML metadata or OIDC parameters required on both sides of the connection.
Step 4: Verify and Enforce
Once the connection is established, verify sign-in with a test user. When you are satisfied that authentication works end to end, notify OpenBOM support. We confirm the final domain policy configuration for your organization, including SSO enforcement where you require it.
Responsibility summary: Your team controls the identity provider connection, the authentication policies applied at sign-in, and the list of users provisioned in OpenBOM. OpenBOM enables SSO for your subscription, registers your domain, and applies the final domain policy you specify.
Questions from IT and Security Teams
Does OpenBOM store our users’ passwords?
No. For SSO users, authentication happens entirely within your identity provider. OpenBOM receives only a signed identity assertion and never handles corporate credentials.
Can we enforce multi-factor authentication for OpenBOM access?
Yes. Because authentication is delegated to your identity provider, any MFA policy you enforce there applies to OpenBOM sign-in automatically, with no separate configuration in OpenBOM.
What happens when an employee leaves our company?
When you deactivate the user in your identity provider, that user can no longer authenticate to OpenBOM through SSO. We also recommend removing the user from your OpenBOM organization as part of your standard offboarding process so that the membership list stays accurate.
Can users outside our domain access our OpenBOM organization?
Only if your administrator explicitly invites them. OpenBOM does not grant access on the basis of domain membership or successful authentication alone.
Can a user create an OpenBOM account simply by signing in through our identity provider?
No. Just-in-time provisioning is disabled. Accounts must be created by your OpenBOM administrator before a user can access your organization.
What identity data does the authentication platform store?
Only the identity attributes sent from your identity provider, typically name and email address. Credentials are not stored.
Is the authentication infrastructure independently audited?
Yes. WorkOS is SOC 2 Type II certified, compliant with GDPR and CCPA, and undergoes annual third party penetration testing and external code audits.
Can we run SSO and password authentication in parallel during rollout?
Yes. Your domain policy can permit both methods during a transition period, then move to SSO only enforcement once the rollout is verified.
Which protocols are supported?
SAML 2.0 and OpenID Connect. Both are configured through the guided setup portal using your own identity provider credentials.
Does OpenBOM need administrative access to our identity provider?
No. Your IT team performs the connection using your own administrative access. OpenBOM does not require or request credentials for your identity provider.
Getting Help
To enable SSO for your company, or to request security and compliance documentation for a vendor review, contact the OpenBOM team. We will guide you through the configuration process and respond to questions from your IT and security organization.
Email: support@openbom.com