---
title: "SSO Architecture Overview"
slug: "sso-architecture-overvie"
updated: 2026-06-23T11:07:02Z
published: 2026-06-23T11:07:02Z
canonical: "help.frisbii.com/sso-architecture-overvie"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.frisbii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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**:

![](https://cdn.document360.io/b84e1b5d-2ba6-4465-8c62-fb45a2f31314/Images/Documentation/frisbii_sso_login_flow_brand.svg)

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](/frisbii-media/docs/sessions-transfer-tokens). For a full implementation walkthrough see [Building an ID System/Centralised SSO](/frisbii-media/docs/id-system-centralized-sso).

---

## Choosing between OAuth 2.0 and cookie-based SSO

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

|  | OAuth 2.0 | Cookie-based |
| --- | --- | --- |
| **Recommended?** | ✅ Yes | Only for legacy integrations |
| **How session is passed** | Access code → token exchange (server-to-server) | `plenigo_user` cookie read server-side |
| **Refresh tokens** | Yes — long-lived sessions without re-login | No |
| **CSRF protection** | Built-in via `state` parameter | Not applicable |
| **Frisbii Media API version** | v2 OAuth endpoints | v2 cookie endpoint |

---