SSO Integration: Embedded Cyber Safety & Identity Products
If your goal is to authenticate users into a Gen-owned property (e.g., the Norton Portal at my.norton.com) using your IdP, that is a separate integration covered by the Partner Portal SSO documentation. Please contact your Gen technical representative for access to that guide.
Note: This SSO integration is only applicable for Gen's cyber safety solutions. It does not support Engine's embedded financial marketplaces.
1. What is the Gen SSO Integration?
Gen provides a standards-based Single Sign-On (SSO) integration that allows your users to access embedded Gen products within your portal or application — such as Identity Protection or Anti-Scam — using the accounts and credentials managed by your IdP.
At the core of this integration is Gen's central identity service (referred to internally as Norton Secure Login or NSL). NSL acts as a secure broker between:
Your IdP (where your users authenticate), and
Embedded Gen products (e.g., Identity Protection SDK / SPA, Anti-Scam) deployed within your portal or application.
At a high level:
The integration is designed to:
Keep user authentication under your control.
Allow Gen to respect your identity, security, and session policies.
Minimize friction for end users with SSO and "remember this device" experiences (where supported by your IdP and our joint configuration).
The integration is intended for Gen partners who:
Embed Gen products within their own portal or application (e.g., Identity Protection, Anti-Scam), and
Operate an enterprise-grade IdP that supports standard protocols.
In all cases, you remain the primary IdP for your users, and Gen respects your account lifecycle and access policies.
2. Supported Standards & Integration Options
Gen's SSO integration supports standard identity protocols that most enterprise IdPs already implement.
2.1 Protocols
NSL can integrate with external IdPs over:
SAML 2.0
OAuth 2.0
OpenID Connect (OIDC)
The right choice depends on your use case and where SSO is needed:
Embedded Gen product in a partner web portal (browser-based)
Any of SAML 2.0, OAuth 2.0, or OIDC can be used.
Embedded Gen product in a partner native app
Typically requires OAuth 2.0 or OIDC, because they provide the token types needed for device-friendly sign-in and session renewal.
All embedded Gen products (Identity SDK / SPA, Anti-Scam, and similar)
Use OAuth 2.0 / OIDC-style token flows between your IdP and NSL, and between NSL and the embedded Gen product.
As a prerequisite, your IdP implementation must be fully compliant with the chosen standard, or you must clearly document any deviations so they can be evaluated jointly.
3. High-Level Architecture & Flows
This section intentionally stays high-level and omits environment-specific URLs, credentials, and sample tokens. Those details are shared privately during onboarding.
3.1 Overall Architecture
Conceptually, the integration looks like:
NSL never becomes your IdP. Instead, it trusts your IdP and translates your identity into Gen's internal authorization model.
3.2 Token Exchange – Two Common Patterns
NSL supports multiple patterns to consume trust from your IdP. Two common ones:
Pattern A – JWT Access Token Exchange (Recommended in Many Cases)
This is typically the preferred approach when your IdP already exposes well-structured JWT access tokens.
Pattern B – Authorization Code Exchange
This pattern requires a fully browser-based flow and involves additional coordination (hidden iframes, front-end scripts, and back-end calls). Many partners find the JWT access-token exchange simpler operationally.
4. Native App Embedding Considerations
When Gen identity features are embedded within a partner's native application (e.g., an installed mobile or desktop app):
The client typically needs a way to maintain a signed-in state without forcing the user to re-authenticate frequently.
This is achieved using refresh-token-style mechanisms (as defined by OAuth 2.0 / OIDC) and device-level session management.
To support this, your IdP must:
Issue tokens with appropriate lifetimes, and
Allow those tokens to be safely renewed according to the jointly agreed security policy.
On the Gen side, NSL can support "remember me on this device" behaviors where policy allows, so users do not need to enter credentials every time they launch the product.
Exact token lifetimes, renewal policies, and device behavior are agreed during solution design and are not part of this public-level overview.
5. Example Flow: SSO for Identity SDK / Embeddable SPA
This section describes the SSO token flow for any embedded Gen product — including the Identity Protection SDK / SPA and Anti-Scam. The pattern is consistent across products; the specific NSL endpoints and configuration details for each product are provided during onboarding.
Gen provides embeddable product components that allow you to:
Surface Gen product capabilities (e.g., identity theft protection, anti-scam detection) directly inside your portal or native app.
Maintain a consistent SSO experience using your IdP, regardless of which Gen product is embedded.
5.1 Initial Token Flow
At a high level:
User signs into your portal/app using your IdP.
Once authenticated, your backend obtains a partner token or authorization code from your IdP.
Your backend calls an NSL token endpoint to redeem that token/code for NSL tokens — typically an NSL access token and, where supported, an NSL refresh token.
Your portal or app passes the NSL access token when loading or interacting with the embedded Gen product.
The embedded Gen product trusts NSL and uses the NSL access token to authorize user access to Gen features.
This keeps your login experience fully under your control while ensuring the embedded product is securely authorized by Gen.
5.2 Token Refresh & Session Continuity
NSL access tokens have a finite lifetime. For embedded experiences where users may remain active for extended sessions, your integration should account for token renewal:
If NSL issues a refresh token alongside the access token (subject to policy and configuration), your backend can use it to obtain a new NSL access token without requiring the user to re-authenticate.
When the NSL access token nears expiry, your backend should proactively exchange the refresh token for a fresh access token and supply the updated token to the embedded Gen product.
If no refresh token is available, or if the refresh token has itself expired, your backend must re-initiate the partner token exchange (Steps 2–3 above) using a still-valid partner session. This is typically transparent to the user if their session with your IdP remains active.
Refresh token lifetimes and rotation policies are jointly agreed during solution design and align with your IdP's session and security policies. These details are not part of this public-level overview.
Partners should design their backend token-management logic to handle refresh proactively rather than reactively (i.e., before the embedded Gen product surfaces an authorization error to the user).
6. Information You'll Need to Provide
To configure a secure SSO integration, Gen will ask you to provide IdP metadata and configuration details appropriate to your chosen protocol. Examples include:
6.1 For SAML 2.0 Integrations (Conceptual)
Issuer / Entity ID – Unique identifier for your IdP.
SSO & SLO endpoints – URLs where NSL redirects or posts authentication and logout requests.
Bindings – HTTP-Redirect vs HTTP-POST for authentication and logout.
Public signing keys / certificates – Used by NSL to validate your SAML responses.
Attribute mapping – Which attributes are returned in the assertion and which one uniquely identifies the user.
Sample (dummy) SAML response – For mapping and testing purposes (with non-production data).
6.2 For OAuth 2.0 / OpenID Connect Integrations (Conceptual)
Authorization endpoint – Where users are sent to sign in.
Token endpoint – Where NSL or your backend obtains tokens.
User info / profile endpoint (if used) – Where additional user profile data can be retrieved.
Client configuration – How client IDs/secrets are provisioned on your side and what format NSL should expect.
Supported scopes and claims – At minimum, a stable, unique user identifier is required; profile and email-related claims are often used.
Token format details – For JWT access-token exchange scenarios, the structure of the JWT (issuer, audience, signing algorithm, key identifiers, etc.).
Sample (dummy) token response – For mapping and validation (with non-production data).
6.3 General Partner Inputs
Across all protocols, Gen will also typically ask for:
Non-production and production IdP endpoints (provided securely).
Test account(s) dedicated to SSO integration testing.
Technical point of contact (engineer/architect) to work with the Gen team during design, implementation, and troubleshooting.
Declaration of any non-standard behavior in your SAML/OAuth/OIDC implementation.
All concrete URLs, keys, certificates, and token examples are exchanged through secure, access-controlled channels and are not included in this external-level guide.
7. Security & Data-Protection Posture
While detailed security policies are documented internally, at a high level:
The integration is designed to comply with Gen's Information Classification and Handling Standard and broader security policies.
Sensitive items such as credentials, access keys/tokens, tenant identifiers, internal IPs or network details are treated as non-public and are never embedded in public-level documentation.
All environment-specific values (e.g., API endpoints, headers, tenant IDs, and token examples) are shared only with authenticated counterparts and, where applicable, under appropriate contractual or NDA coverage.
Partners should apply equivalent controls on their side to protect any shared configuration or tokens related to the integration.
8. Onboarding & Next Steps
A typical onboarding sequence looks like:
For any detailed, environment-specific API specifications, onboarding checklists, or example payloads, your Gen contact will share the appropriate partner-only technical documentation separately.
Last updated
Was this helpful?