Session API

Opaque local-session lifecycle and optional browser OIDC sign-in

📄️List current-member external sign-in methods

Requires a normal authenticated session; personal access tokens are rejected. Returns provider ID, authentication method, and link time only; immutable external subjects are never disclosed.

📄️Link a verified LDAP/AD credential to the current member

Requires a recent ordinary session and an exact same-origin proof for cookie requests. The LDAP password is verified against the configured TLS-protected directory, zeroized after use, and the verified identity is bound only to the current member.

📄️Begin an OIDC identity-linking ceremony

Requires a normal authenticated session and a same-origin cookie request. The verified callback can only add a credential to that exact recently authenticated local account; it cannot admit a new account or issue a replacement session.

📄️Link the protected proxy assertion to the current member

Requires a recent ordinary session and an exact same-origin proof for cookie requests. Accepted only from a configured direct proxy peer supplying the deployment secret and bounded identity headers; the verified assertion is bound only to the current member.

📄️Unlink an external sign-in method after a recent sign-in

Revokes every active session issued by the unlinked identity. The last interactive credential cannot be removed.

📄️Verify a TLS-protected LDAP/AD password and issue a local session

Requires same-origin JSON. The password is verified only against the configured TLS-protected directory and then zeroized. An unknown identity is admitted only through the provider's invitation or required-group policy before Jiandu issues its own opaque session.

📄️Report enabled browser sign-in methods

Unauthenticated discovery response. It exposes initial setup availability, local-method booleans, and configured provider IDs and display names; issuer, client, admission-policy, group, invitation, and account details remain hidden.

📄️Complete the OIDC browser callback

Consumes the one-use OIDC state and creates the normal opaque Jiandu session before redirecting to the application. Browser JavaScript never receives the provider token.

📄️Begin an OIDC authorization-code + PKCE browser flow

Requires same-origin JSON. The result is an authorization URL and a short-lived host-only HttpOnly SameSite=Lax correlation cookie; no provider tokens are returned to browser JavaScript.

📄️List current-member passkey metadata

Requires a normal authenticated session; personal access tokens are rejected. Returns only Jiandu credential IDs, labels, and use timestamps, never public-key material or raw WebAuthn credential bytes.

📄️Consume a passkey assertion and issue an opaque session

Requires same-origin JSON and consumes the one-use server-side ceremony before verification. Success atomically advances the stored credential state and issues a host-only HttpOnly SameSite=Strict session cookie.

📄️Begin username-first passkey authentication

Requires same-origin JSON. Credential descriptors are padded and unknown usernames receive decoys; the one-use ceremony state remains server-side and expires after five minutes.

📄️Atomically consume an invitation, persist a passkey, and issue a session

Requires same-origin JSON. It consumes the one-use ceremony and atomically revalidates and consumes the invitation while creating the member, passkey, audit event, and opaque session; no raw invitation token is retained.

📄️Begin invitation-backed passkey admission

Requires same-origin JSON. The invitation is validated without being consumed, then only its digest, the prospective member fields, and the one-use five-minute ceremony state are retained server-side.

📄️Verify and persist a passkey for the current member

Requires the same recent ordinary session and an exact same-origin proof for cookie requests. It consumes the one-use ceremony, verifies its member and session binding, and atomically persists the credential subject to username, freshness, and passkey-capacity checks.

📄️Begin passkey enrollment after a recent ordinary sign-in

Requires a recent ordinary session and an exact same-origin proof for cookie requests. The five-minute one-use ceremony is bound to that member and session, normalized username, and label, and excludes already registered credentials.

📄️Revoke one current-member passkey after a recent sign-in

Requires a recent ordinary session and an exact same-origin proof for cookie requests. Revocation is audited, revokes sessions issued by that credential, and cannot remove the last interactive credential; an Owner recovery path, local password, another passkey, or linked external identity must remain.

📄️Exchange a protected reverse-proxy assertion for a local session

Accepted only from a configured direct proxy peer supplying the deployment secret and bounded identity headers. Client-supplied identity headers alone are never authority.

📄️Revoke supplied session credentials and expire a supplied browser cookie

Logout is idempotent. A cookie, ordinary bearer session, both, or neither may be supplied; any supplied recognized session credentials are revoked. Personal access tokens cannot use this credential-management route. Browser requests are subject to same-origin checks.

📄️Verify the current session and rotate it when due

Supply exactly one credential source: the session cookie or an opaque bearer token. Rotation preserves the response shape and may include a replacement Set-Cookie header.

📄️Exchange a local recovery token or username/password for an opaque session

The recovery token or password is accepted only in this JSON body and is never persisted by the session store. Browser requests are subject to same-origin Fetch Metadata and Origin checks. The returned credential is set as a host-only HttpOnly SameSite=Strict cookie.