Connect Presence

Use Presence to sign in to your website. Connect your company directory to keep access up to date.

Website sign-in

Create an application in Enterprise → Integrations. Save its client secret on your server. A Test application is separate from Live; verify your domain before using Live.

Next.js / Auth.js

Download the server configuration. Use next-auth@5.0.0-beta.32 or a later security-patched v5 version with @auth/core 0.41.3 or later. The adapter is tested against Auth.js core 0.41.3. It uses discovery, PKCE, state, nonce and signed ID tokens. Email-based account linking is disabled.

import NextAuth from "next-auth";
import { presenceAuthConfig } from "./presence-authjs.mjs";
export const { handlers, auth, signIn, signOut } =
  NextAuth(presenceAuthConfig(process.env));

Export GET and POST from handlers in app/api/auth/[...nextauth]/route.ts. Register https://YOUR-WEBSITE/api/auth/callback/presence as your Presence callback.

PRESENCE_ISSUER=copy-from-your-Presence-application
PRESENCE_CLIENT_ID=your-application-id
PRESENCE_CLIENT_SECRET=your-server-secret
AUTH_SECRET=at-least-32-random-bytes
AUTH_URL=https://YOUR-WEBSITE

Start sign-in from a server action with await signIn("presence"). On every protected server page, API route and server action, call auth() and require session?.user?.id. Apply your own application permissions too. Hiding a button or protecting only the page layout does not protect an API.

The adapter checks token activity for every session read and denies access on timeout. Sessions last at most five minutes; continuing afterwards requires a new sign-in. Tokens stay in encrypted HttpOnly cookies and are not returned by the session endpoint. Validate account identity using issuer plus subject; never attach an existing account merely because its email matches.

Node.js and other OIDC applications

Follow the complete setup guide or download the runnable Node.js website. Both the example and Auth.js adapter report callback and access-check results to Enterprise.

Keycloak

In your realm, add an OpenID Connect identity provider named Presence. Import discovery from the issuer shown in your Presence application plus /.well-known/openid-configuration. Enter the client ID and secret, enable PKCE with S256 and signature validation, and use client_secret_basic. Register the exact broker callback displayed by Keycloak in Presence.

Keep Trust Email, automatic linking to existing accounts and stored-token access disabled unless you have separately designed and reviewed those flows. Keycloak has its own sessions: standard brokering alone does not propagate a Presence access withdrawal to existing Keycloak sessions. Before rollout, implement server-side activity checks and test revocation. These are configuration instructions, not a certified connector or a completed customer-tenant test.

WordPress

A direct WordPress connector is not released yet. The reviewed OpenID Connect Generic Client does not implement the PKCE flow Presence requires. Do not disable PKCE or ID-token signature validation to connect a plugin. Use a reviewed OIDC integration once it supports both; no one-click WordPress compatibility is claimed.

Microsoft Entra ID and Okta

Use the SCIM 2.0 API to provision company people and groups. It changes company access, not personal Presence accounts, Keys, passkeys or recovery. People still create and verify their own Presence account. Provisioning does not send invitations.

1. Open Enterprise → People → API. Create a credential with only scim:read and scim:write. Save it once in your identity provider’s secret store.
2. Use https://presence.by4si.com/scim/v2 as the SCIM base URL and the credential as the bearer token. For Preview, use the Preview origin and a separate Preview credential.
3. In Entra, create a non-gallery enterprise application and choose automatic provisioning. In Okta, configure a custom SCIM 2.0 integration with bearer authentication. Start with a small assigned test group, not your entire directory.
4. Map the attributes below, test the connection, then provision a person and a group.
5. In Presence, assign that group to a website with the “Only assigned people or groups” policy. Complete a Key and passkey sign-in, then deactivate the person in the directory. Confirm that the website denies the next protected request.

Remove default mappings for unsupported attributes such as title, department, manager, phone and addresses. The schema endpoints describe the supported fields. Do not use a UPN different from the person’s verified Presence email. Email changes require administrator identity review; they cannot silently transfer access to a different account.

Access and lifecycle rules

A directory disable blocks new sign-ins and revokes existing company grants. Re-enabling a directory entry does not remove a manual Presence suspension or expired access date. The SCIM active field represents directory state; the Enterprise UI also shows manual holds.

Deleting a SCIM person retires their company entry, removes group memberships and direct assignments, and retains the identity reservation for review. A new account with the same email cannot inherit that access. Their personal Presence account remains intact. Group deletion withdraws its assignments. Recreating deleted names or external IDs requires administrator review rather than automatic resurrection.

Credentials expire after at most 90 days. Rotate them before expiry, test the replacement, then revoke the old credential. Removing the creating administrator’s company role disables that credential. Use a dedicated named company administrator with an accountable owner; never a shared personal passkey.

Protocol coverage

Download the SCIM OpenAPI reference

Users and Groups support GET, POST, PUT, PATCH and DELETE. Discovery endpoints: ServiceProviderConfig, ResourceTypes and Schemas. Equality filters support userName, displayName, externalId and id. Pagination uses startIndex (one-based) and count (0–100). Groups hold up to 500 people. PATCH supports add/replace/remove and filtered group-member removal. Conditional writes accept If-Match. Bulk, sorting, passwords, nested groups and arbitrary SCIM extensions are not supported.

Responses use standard SCIM error envelopes. A duplicate returns 409; a stale version 412; throttling returns 429 with Retry-After. Unsupported filters and attributes are rejected rather than ignored. Scope and tenant checks apply to discovery as well. SCIM clients need no custom Idempotency-Key header; the separate management API requires one for writes.

The API is covered by protocol, isolation and revocation tests. Microsoft and Okta tenant acceptance and gallery certification remain separate steps; no customer directory is connected automatically.

Back to Enterprise · Management API · OIDC guide