auth-api

GET /.well-known/jwks.json

Jwks

GET /.well-known/openid-configuration

Openid Config

Maskinidentitetsytan — och EN hänvisning vidare (D-71, Task 6). Fälten nedan beskriver `/v1/token/client`: client_credentials, hemlighet i `client_secret_basic`. De är oförändrade sedan tjänsten byggdes, med flit. Auktoriseringsserverns yta (Task 3-5) bor på en ANNAN token-endpoint (SDK:ns `/token`, publika klienter, PKCE), och OIDC-discovery har bara ett `token_endpoint`-fält — att peka om det hade tyst brutit varje integratör som läst det här dokumentet för att nå maskinidentitetsvägen. Alltså: två dokument, ett per yta, och en länk mellan dem i stället för ett dokument som ljuger om någondera. `oauth_authorization_server_metadata` är ingen registrerad OIDC-parameter, men OIDC Discovery 1.0 §3 tillåter ytterligare metadata — samma undantag och samma husform som Task 4:s `resource_indicators_supported` i RFC 8414-dokumentet. Länken sätts BARA när OAuth-ytan faktiskt är rest (`oauth_enabled` är all-or-none). Att peka på ett dokument som svarar 404 vore att byta ut en ofullständig sanning mot en osann.

GET /healthz

Healthz

Liveness: process is alive. No deps check.

GET /readyz

Readyz

Readiness: process can serve traffic. Checks deps.

GET /v1/admin/tenants/{tenant_id}/channel-identities

List Channel Identities

DELETE /v1/admin/tenants/{tenant_id}/channel-identities/{channel}/{team_id}/{external_user_id}

Unmap Channel Identity

Ta bort mappningen. Idempotent; `removed` säger om något fanns. Gäller nästa anrop mot `/v1/token/channel`. Redan utfärdade token lever till sin `exp`, av samma skäl som för återkallad delegering.

PUT /v1/admin/tenants/{tenant_id}/channel-identities/{channel}/{team_id}/{external_user_id}

Map Channel Identity

Mappa kanalkontot till personen med den här e-posten. Idempotent. Samma person igen: ingen ändring, ingen auditrad. Annan person: raden skrivs om och auditas med `previous_user_id`, så en ommappning aldrig ser ut som en första mappning i kedjan.

Kropp: ChannelIdentityPut application/json

GET /v1/admin/tenants/{tenant_id}/export

Export Tenant

DELETE /v1/admin/tenants/{tenant_id}/group-mappings

Delete Mapping

GET /v1/admin/tenants/{tenant_id}/group-mappings

List Mappings

POST /v1/admin/tenants/{tenant_id}/group-mappings

Create Mapping

Kropp: GroupMappingCreate application/json

GET /v1/admin/tenants/{tenant_id}/role-bindings

List Bindings

POST /v1/admin/tenants/{tenant_id}/role-bindings

Create Binding

Kropp: RoleBindingCreate application/json

DELETE /v1/admin/tenants/{tenant_id}/role-bindings/{user_id}

Delete Bindings For User

GET /v1/admin/tenants/{tenant_id}/service-clients

List Service Clients

Tenantens service clients — aldrig `client_secret_hash`, aldrig hemligheten.

DELETE /v1/admin/tenants/{tenant_id}/service-clients/{client_id}/channel

Revoke Channel

Ta tillbaka `token:channel`. Gäller nästa anrop mot `/v1/token/channel`.

PUT /v1/admin/tenants/{tenant_id}/service-clients/{client_id}/channel

Grant Channel

Slå på `token:channel` (`P3`, D-146). Idempotent, additivt — samma form och samma gränser som delegeringsrätten ovan.

DELETE /v1/admin/tenants/{tenant_id}/service-clients/{client_id}/delegation

Revoke Delegation

Ta tillbaka `token:delegate`. Idempotent. Svarar 200 med den uppdaterade raden och inte 204: en administratör som just tagit tillbaka en rättighet ska se att `delegation_allowed` är `false`, inte behöva lita på det. Återkallandet gäller nästa anrop mot `/v1/token/delegate`. Redan utfärdade delegerade token lever till sin `exp` — de är signerade och inte uppslagsbara, och en spärrlista är en egen mekanism med eget felläge.

PUT /v1/admin/tenants/{tenant_id}/service-clients/{client_id}/delegation

Grant Delegation

Slå på `token:delegate` för klienten. Idempotent. Additivt: bara scopet i fråga rörs, resten av listan lämnas som den är.

GET /v1/admin/tenants/{tenant_id}/users

List Users

POST /v1/admin/tenants/{tenant_id}/users

Invite User

Kropp: UserInviteRequest application/json

POST /v1/admin/tenants/{tenant_id}/users/{user_id}/enable

Enable User

POST /v1/admin/tenants/{tenant_id}/users/{user_id}/erase

Erase User

POST /v1/admin/tenants/{tenant_id}/users/{user_id}/export

Export User

POST /v1/admin/tenants/{tenant_id}/users/{user_id}/revoke

Revoke User

GET /v1/me

Me

GET /v1/oauth/callback

Oauth Callback

Andra benet: användaren är tillbaka från kundens IdP.

POST /v1/token/channel

Token Channel

Kanalkonto → plattforms-JWT för personen bakom det (`P3`, D-146). Ett Slack-user-ID är ingen identitet. Rutten slår upp `(kanal, workspace, kanal-användare)` i `auth.channel_identities` och myntar personens token med kanaladaptern som `act`. **Saknas raden är svaret 403 `channel_identity_unmapped` — det finns ingen andra väg** (#208, OWASP ASI03). `tools/checks/check_no_channel_service_fallback.py` fäller syntaktiskt om uppslaget, det hårda felet eller förbudet mot `mint_service` försvinner ur den här funktionen; täckningsgränsen står i vakten. Tillitsmodellen, utskriven: tokenet myntas på anroparens ord plus vår mappning, inte på en IdP-inloggning. Anroparen är en service-client med `token:channel`, samma tillitsnivå som `token:delegate`; skillnaden är att delegeringen får ett verifierat subjekt-token medan kanalvägen får ett kanal-ID adaptern påstår. Mappningen skrivs bara av tenant-admin. Roller, scopes och grupper kommer ur databasen som efter en inloggning (`RoleResolver`), aldrig ur anropet: adaptern kan inte välja dem. Varje nekande skrivs och committas före `raise`; metadata bär BARA `reason`, aldrig kanal-ID eller e-post — det är angriparvalda strängar. Nekandets `tenant_id` är alltid KLIENTENS (`None` för en plattformsklient), aldrig kroppens: samma invariant som `_deny_delegation` motiverar.

Kropp: TokenChannelRequest application/json

POST /v1/token/client

Token Client

Kropp: TokenClientRequest application/json

POST /v1/token/delegate

Token Delegate

RFC 8693-delegering (P2a, D-101): agenten byter användarens token mot ett där `sub` fortfarande är människan och `act` namnger agenten. Rutten UPPRÄTTHÅLLER ingenting nedströms — den bara utfärdar. Att avvisa anrop utan `act` är P2. Vad den däremot gör är att aldrig utfärda mer än den fick: roller, scopes och grupper kopieras verbatim från subjekt-tokenet och livslängden kapas till dess återstående liv. **Känd gräns — ett subjekt-token med `aud` går inte att delegera.** Verifieraren konstrueras utan `expected_audience`, och `JWTVerifier` är binär i den frågan (D-71): utan deklarerat namn avvisas varje token som BÄR `aud`. Följden är att tokens från OAuth-/RFC 8707-vägen (som sätter `aud` till MCP-resursen) svarar 401 `subject_token_invalid` här, medan tokens från `/v1/token/exchange` (utan `aud`) fungerar. Gränsen är medvetet inte "fixad" genom att skicka en audience till verifieraren — det hade försvagat audience-isoleringen, som är en säkerhetsegenskap, och valet av vilken audience som ska accepteras hör inte hemma i P2a. Låst av `test_subject_token_with_audience_cannot_be_delegated`. Varje nekande skrivs till auditkedjan och COMMITTAS före sitt `raise` (fail-closed) — även de som avvisar själva subjekt-tokenet. Det är just de vägarna en agent som prövar stulna, utgångna, tjänste- eller redan delegerade token går, och en tyst sådan väg lämnar ingen spårbar sondering efter sig. Metadata bär BARA `reason`: aldrig subjekt-tokenet, aldrig dess claims (GDPR first — rutten hanterar legitimationer).

Kropp: TokenDelegateRequest application/json

POST /v1/token/exchange

Token Exchange

Kropp: TokenExchangeRequest application/json