Opti ID Security

The introduction of Optimizely CMS 13 (PaaS) represents a fundamental shift in how identity and access management are handled within the digital experience landscape. Central to this evolution is Opti ID, a mandatory, centralized authentication service designed to unify the user experience across the entire Optimizely One suite. However, for developers and architects, understanding the absolute boundaries of Opti ID is critical for designing secure, scalable applications. A common strategic point of confusion is the distinction between "Product Users"—those who manage the platform—and "Public Visitors"—the end-users who consume content on the live site. This article provides an extensive deep-dive into the security domains of Opti ID, clarifying what it protects, how it interfaces with modern security standards like OIDC, and why it deliberately excludes visitor-facing authentication from its scope.

The Identity Evolution: Why Opti ID is Mandatory

In previous iterations of the Optimizely platform (CMS 11 and 12), authentication was often localized or instance-specific. Each product instance typically maintained its own user database or integrated independently with an organization's Active Directory. While functional, this "siloed identity" model created significant authorial friction. Content editors were often forced to manage multiple sets of credentials, and developers had to configure authentication providers repeatedly across dev, test, and production environments.

Opti ID solves this by moving the identity authority upstream. It serves as a single source of truth for every "Product User" in the organization. By centralizing identity, Optimizely enables advanced capabilities like Optimizely Opal (the AI agent orchestration platform) and seamless cross-product workflows. For example, an editor can transition from planning a campaign in Optimizely Content Marketing Platform (CMP) to building a page in the CMS without needing to re-authenticate. This is the cornerstone of the "Optimizely One" unified platform strategy.

Domain 1: What Opti ID Secures (The Product User)

Opti ID is strictly engineered to secure Product Users. In the architectural context of CMS 13, a Product User is any individual or automated service principal that requires access to the Optimizely management interfaces, the experimentation engine, or high-privilege administrative APIs.

Categories of Product Users

• Content Editors and Marketers: Power users who spend their time in standard Edit mode, Visual Builder, and Content Manager to curate digital experiences. They require persistent sessions that can survive cross-product jumps without friction.
• System Administrators: Strategic users who configure site settings, manage global languages, and oversee permission hierarchies within the Admin UI. Their access is often federated from corporate directories like Azure AD.
• Technical Developers: Users who need access to the platform for configuration, telemetry, troubleshooting, or utilizing the CMS Management APIs. Developers use Opti ID to secure their local-to-cloud connections during development.
• Service Principals and CI/CD: Programmatic users used for CI/CD pipelines or backend automated processes that interact with the CMS infrastructure. These users often leverage client credentials to obtain tokens for automated content synchronization.

The Security Mechanism: OIDC and JWTs in Depth

For these users, Opti ID acts as a sophisticated OpenID Connect (OIDC) provider. When a user attempts to log into the CMS backend, the system triggers a redirection to the Opti ID login portal. Upon successful authentication—whether via Opti ID's local login or a federated SSO like Microsoft Entra ID or Okta—Opti ID issues a JSON Web Token (JWT).

This JWT serves as the user's permanent "passport" within the system during their session. It contains critical claims used for authorization:

• sub (Subject): The consistent unique identifier for the user across the entire Optimizely organization.
• email: The user's verified authenticated email address, used for cross-product identification.
• cg-roles: Specific roles that define what the user corresponds to in the CMS (e.g., WebEditors, Administrators). These roles are mapped during the login handshake from the user's groups.

Domain 2: What Opti ID Does Not Secure (The Public Visitor)

A critical architectural boundary that developers must plan for is that Opti ID does not manage visitor logins for your frontend website. It is purposefully not a Customer Identity and Access Management (CIAM) solution.

Defining the Public Visitor Scope

A public visitor is anyone accessing the live, rendered version of your application. This encompasses:

• Standard shoppers browsing an e-commerce storefront who expect high-speed, personalized interactions.
• Registered customers logging into a private "My Account" area to track orders, manage biometrics, or update preferences.
• Forum or community members engaging in social interactions or user-generated content (UGC).

The Rationale Behind Identity Separation

Optimizely has made a deliberate design choice to decouple product-level management users from site-level visitors. There are several strategic advantages to this separation:

1. High Performance at Massive Scale: Product user bases are typically small, requiring rigorous security overhead. Public visitor bases, however, can scale into the millions. These visitors require highly performant, globally distributed authentication systems (like Firebase, Auth0, or custom identity tables) that shouldn't be constrained by the heavy corporate OIDC policies used for internal employees.
2. Regulatory Privacy and Compliance: Frameworks like GDPR and CCPA often mandate different data handling for corporate employees versus external customers. Keeping these identities separate simplifies the auditing process and risk management profile of the organization.
3. Frontend and Framework Flexibility: Since CMS 13 is "Headless-First," Optimizely ensures you are not locked into a specific customer identity provider. Whether you are using Next.js with NextAuth or a native iOS app using Apple ID, you are empowered to choose the identity stack that fits your customers best. This allows for modern features like social login or passwordless auth that Opti ID does not prioritize.

Security Boundaries in Content Delivery: SingleKey vs. Bearer

Understanding the interplay between Opti ID and public content delivery is essential for developers working with Optimizely Graph. There are two distinct access paths that effectively gate individual content versions:

1. Public Access (HMAC SingleKey)

Your frontend application uses a public-facing API key (the SingleKey) to fetch content for standard visitors. This key is cryptographically restricted to return only Published content. It maintains no individual "identity"—it simply represents the authenticated site's right to show public data to the world. It provides the maximum possible performance through CDN caching.

2. Authenticated Access (JWT Bearer Token)

When an editor is in Preview mode, the CMS/Opti ID issues a JWT. The frontend extracts this token and passes it in the Authorization: Bearer header. Optimizely Graph recognizes this as a verified Opti ID identity and allows the query to return Draft and Unpublished versions. This "Step-Up" authentication ensures that sensitive draft content remains invisible to the public SingleKey requests, providing a secure sandbox for editorial work.

Practical Implications for CMS Developers

When building or upgrading to CMS 13, developers must account for these identity domains in their system design:

• Mandatory Enrollment: All members of development and editorial teams must be invited to the Opti ID organization. Local "User Creation" in the SQL database is no longer supported for administrative or editorial access.
• Role Mapping from Groups: Permissions within the CMS are still governed by traditional roles (like CmsEditors), but these should be mapped from groups defined within Opti ID or your federated IDP. Developers must configure the claim-to-group mapping to ensure users get the correct UI permissions upon login.
• Frontend Identity Design Strategy: If your project requires a "Customer Login," you must architect that solution independently of Opti ID. Your frontend will likely manage two distinct session states: one for the end-customer (persistent) and one (temporary) for the Opti ID editor session during preview. This separation allows you to build customer-facing features like "Recently Viewed Items" or "Favorites" without interfering with CMS management logic.

Governance and Lifecycle Management

Because Opti ID is the gateway to the entire platform, its management becomes a high-priority developer task. This includes configuring SCIM provisioning for automatic onboarding from corporate directories and managing the technical contact who holds the initial keys to the organization. Developers must also be aware of token expiration cycles (typically short-lived for security) and ensure their frontend preview handlers can request new tokens via the communicationinjector.js bridge when needed.

Conclusion

Opti ID serves as the unified security gateway for the modern Optimizely platform, ensuring that Product Users have a seamless and secure experience across the entire suite. By deliberately separating these management identities from Public Visitors, Optimizely provides developers with the architectural freedom to scale customer-facing applications using any identity provider while maintaining rigorous control over the content management backend. For the CMS 13 developer, the core rule remains the guiding light: use Opti ID to secure the makers, and choose your own path to secure the consumers.