SSO Architecture Overview

Frisbii Media supports two fundamentally different approaches to user authentication. Choosing the right one depends on whether you want Frisbii Media to manage your users, or whether you already have your own user management system.

Approach 1 – Frisbii Media as your SSO provider

Frisbii Media handles login, registration, password reset, and two-factor authentication. Your website delegates authentication entirely to Frisbii Media. This is the recommended approach for new integrations.

How it works:

1. A visitor clicks "Login" on your website

2. The Frisbii Media JavaScript SDK renders a login iframe

3. The user logs in; the SDK fires plenigo.LoginSuccess with a customerSession

4. You pass the customerSession to your backend, which stores it in the server-side session

5. All subsequent access checks and API calls use this session

When to use:

• New projects without an existing user base

• You want to offer Frisbii Media's self-service portal (Snippets) without custom development

• You do not need to maintain a separate user database

Approach 2 – External user management

You maintain your own login and user database. Frisbii Media only handles checkout and access rights. Your users are identified in Frisbii Media by your internal user ID (customerId or externalSystemId).

How it works:

1. The user logs in to your own login system

2. Your backend calls POST /customers to create or retrieve the user in Frisbii Media

3. You pass the Frisbii Media customerId directly to preparePurchase for checkout, or to hasAccess for access checks

4. No Frisbii Media session is needed unless you also use the self-service portal

When to use:

• You already have an existing user base and login system

• You do not want to migrate users to Frisbii Media SSO

• You need tight control over the login UX

ID system architecture (multi-website SSO)

If you need SSO across multiple websites — including websites on different domains — the recommended architecture is a centralised ID system:

Key properties of this architecture:

• The ID system (id.domain.com) is the only place that handles Frisbii Media login and maintains sessions

• Other websites receive a short-lived, single-use transfer token via URL — never the session string directly

• If the user already has a session at the ID system, the redirect is transparent (no login prompt)

• Frisbii Media's self-service portal is embedded in the ID system, which already has the customer session

For the transfer token flow see Sessions & Transfer Tokens. For a full implementation walkthrough see Building an ID System/Centralised SSO.

Choosing between OAuth 2.0 and cookie-based SSO

When implementing Frisbii Media as your SSO provider, two technical flows are available: