Implementing SSO, OIDC (All auth) #42
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
psa-systems/mokosh-server!42
Loading…
Reference in a new issue
No description provided.
Delete branch "feature-sso"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This will allow the mokosh-server to act as the backend for authentication for all PSA related products
lets-chat's SSO callback URL changed from /auth/sso/callback to /auth/sso/{provider_id}/callback in its L9 doc-10 pivot. The seeded provider lands under the slug "default", so the redirect_uri lets-chat sends at /auth/sso/start time is /auth/sso/default/callback. Without this fix mokosh-server rejects the authorize request with "invalid redirect_uri". One-off existing rows can be patched in place via: UPDATE mokosh_auth.oauth_clients SET redirect_uris = ARRAY['https://<user>-chat.a8n.run/auth/sso/default/callback'] WHERE name = 'lets-chat';OIDC Back-Channel Logout 1.0 §2.5 requires the OP to notify every RP that has a backchannel_logout_uri registered when an OP session is terminated. Until now mokosh-server revoked the session + refresh-token families locally but never told the RPs, so a user who signed out at Bunyip stayed signed in at drillmark / lets-chat / mokosh-clients until their access token expired (≤1h). After revoking the session, /v1/auth/logout now spawns a background task that: 1. Lists every OAuth client visible to the (user, tenant) via OAuthClientRepository::list_for_user. 2. For each row with backchannel_logout_uri set, mints a signed logout_token (sub=user.id, sid=op_session.sid, aud=client.client_id, events={backchannel-logout}). 3. POSTs `logout_token=<jwt>` as application/x-www-form-urlencoded to the registered URL, 5s timeout, fire-and-forget. Each RP independently does whatever its own webhook handler does. Drillmark's handler stamps users.last_logout_at = NOW(); BearerUser then rejects any access token with iat < last_logout_at, so the revocation lands on the very next API call from the now-signed-out tab. Failures (RP unreachable, RP returned non-2xx, mint error) are logged at WARN and do not block the user's /v1/auth/logout response. The spec mandates a 200 from the RP "within a reasonable time" but doesn't require us to surface RP failure to the human. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>