logaritmisk/biggus-dickus
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases Wiki Activity

OIDC login (external identity provider, relying-party flow) #19

New Issue
Open
opened 2026-06-02 13:22:22 +00:00 by logaritmisk · 0 comments
logaritmisk commented 2026-06-02 13:22:22 +00:00
Owner
Copy Link
Copy Source

Context

The first auth phase delivered email/password login with server-side sessions (tower-sessions) and the Authorized<Cap> extractor framework. OIDC was deliberately split out to keep that plan small. The session/extractor layer is provider-agnostic, so OIDC slots in on top.

What to do (its own plan)

Add an OIDC relying-party flow scoped to the single org:

  • Provider config (issuer/discovery URL, client id/secret, redirect URI) via Config/env.
  • GET /api/admin/oidc/login → redirect to the provider's authorize endpoint (with state + PKCE).
  • GET /api/admin/oidc/callback → exchange code, validate the ID token, map the external identity to a local app_user (provision-on-first-login or match by email — decide), then call the existing auth::establish_session (same session/cookie layer as password login).
  • Decide account linking: does an OIDC identity require a pre-existing app_user, or auto-provision with a default role?

References

  • crates/auth/src/lib.rs — establish_session, the session model
  • crates/server/src/config.rs — config pattern
  • Arch spec §10 (auth); VISION "Authentication & access control".
  • Candidate crate: openidconnect (evaluate vs hand-rolling against discovery).
## Context The first auth phase delivered **email/password** login with server-side sessions (`tower-sessions`) and the `Authorized<Cap>` extractor framework. OIDC was deliberately split out to keep that plan small. The session/extractor layer is provider-agnostic, so OIDC slots in on top. ## What to do (its own plan) Add an OIDC relying-party flow scoped to the single org: - Provider config (issuer/discovery URL, client id/secret, redirect URI) via `Config`/env. - `GET /api/admin/oidc/login` → redirect to the provider's authorize endpoint (with state + PKCE). - `GET /api/admin/oidc/callback` → exchange code, validate the ID token, map the external identity to a local `app_user` (provision-on-first-login or match by email — decide), then call the **existing** `auth::establish_session` (same session/cookie layer as password login). - Decide account linking: does an OIDC identity require a pre-existing `app_user`, or auto-provision with a default role? ## References - `crates/auth/src/lib.rs` — `establish_session`, the session model - `crates/server/src/config.rs` — config pattern - Arch spec §10 (auth); VISION "Authentication & access control". - Candidate crate: `openidconnect` (evaluate vs hand-rolling against discovery).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
logaritmisk
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#19
Delete Branch "%!s()"

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?