Secure your tenant integration

The SSO secret can create Nanaade identities and active memberships for authenticated tenant users when JIT provisioning is enabled. Treat it like a production signing key. Nanaade still derives roles, permissions, licensed modules, and data scope itself.

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.

Map portal actions to a closed set of launch codes on your server. A browser may select one of those actions, but it must not supply a Nanaade path, feature grant, role, entitlement, or unrestricted launch-code string. Nanaade independently resolves every code and checks its licensed feature and audience.

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