Secure your tenant integration

The SSO secret can create assertions for users who already have active memberships. Treat it like a production signing key, even though Nanaade still performs membership and authorization checks.

Store and scope the secret

• Use a managed secret store or encrypted deployment environment variable.
• Grant read access only to the server workload that signs launches.
• Use different credentials for development, staging, and production.
• Never reuse the secret for sessions, encryption, webhooks, or another vendor.
• Prevent it from reaching browser bundles, logs, error trackers, build output, and support tools.

// Safe: server module
const secret = process.env.NANAADE_SSO_SECRET;

// Unsafe: browser-exposed convention
const secret = process.env.NEXT_PUBLIC_NANAADE_SSO_SECRET;

Add .env* to source-control exclusions while committing only a placeholder .env.example.

Create assertions defensively

Authenticate the portal session immediately before launch. Load the permanent user ID from trusted server state—never accept sub or email from query parameters or hidden form inputs supplied by the browser.

Generate 24 or more random nonce bytes for every launch, use Unix seconds, expire within five minutes, and submit immediately. Keep servers synchronized with reliable network time.

const nonce = crypto.randomBytes(24).toString("base64url");
const now = Math.floor(Date.now() / 1000);

Set Cache-Control: no-store, a narrow form-action CSP, and Referrer-Policy: no-referrer on the handoff response.

Safe observability

Recommended event:

{
  "event": "nanaade_sso_launch",
  "requestId": "req_01J...",
  "clientIdSuffix": "...18c2",
  "outcome": "SSO_SIGNATURE_INVALID",
  "occurredAt": "2026-07-21T10:15:00Z"
}

Do not log secrets, full client credentials, signatures, encoded payloads, cookies, or form HTML. Hash or redact user identifiers according to your privacy policy.

Rotation procedure

1. Choose a short overlap appropriate to deployment speed (default 15 minutes, maximum 60).
2. Rotate in Nanaade Admin and copy the reveal-once secret directly to the secret manager.
3. Deploy the new version and run one valid launch.
4. Monitor stable error codes during the overlap.
5. Confirm the previous secret fails after the overlap.

Do not rotate separately on every application instance. All instances should load the same centrally managed active secret.

Suspected compromise

1. Revoke the credential immediately if active misuse is possible.
2. Contact Nanaade through the agreed incident channel with client ID, timestamps, and request IDs—never the secret.
3. Search access/build/log history for the exposure location.
4. Issue a replacement only after removing the leak.
5. Deploy, validate, and document the incident.
6. Review affected membership and launch activity.

Revocation intentionally stops all new exchanges. Existing session handling follows Nanaade's session policy and may require separate operational action.

Threats and controls

| Threat | Primary control | |---|---| | Stolen assertion reused | Single-use nonce and short expiry | | Payload modified | HMAC signature over exact payload | | Redirect to attacker | Exact origin and path allowlists | | Wrong person claims membership | Stable subject binding and active membership | | Feature escalation | Backend entitlement and permission enforcement | | Secret leaked from browser | Server-only signing and secret scanning |