oauth

The client registry an administrator manages: every app that may ask people here for bounded access. The secret of a confidential client is not among the fields - it was answered once, at registration.

A name, the exact redirect URIs it may be sent back to, and whether it can keep a secret. A public client - a native or single-page app - gets no secret and must bring PKCE to every authorization (RFC 7636); a confidential client gets one, in clear, for the only time, stored as a hash under its own purpose label. Redirect URIs match exactly, byte for byte: a prefix or wildcard match is how authorization codes end up on attacker-controlled pages.

The half of a registered client a consent screen needs: its name. Any signed-in member of the workspace may read it, and that is the point - the person deciding whether to allow an app is usually not an administrator, and a consent screen that cannot name the app is a screen that asks somebody to approve an identifier. That is the shape a phishing attempt wants. Deliberately narrower than the listing. The registered redirect URIs and whether the client is confidential are the administrator's business and are answered by GET /oauth/clients behind the permission that manages members; nothing here helps somebody enumerate the workspace's apps, because reading one requires already knowing its identifier - which the authorization request the reader arrived with already carries.

Removes the client and revokes every grant that pointed at it: the sessions those grants leashed refuse on their next request. What people allowed the app is withdrawn with the app, because a grant to a client nobody can name is a door with no label.

The authorization endpoint, headless: the signed-in person - never a token, a person - names the client, the exact redirect URI, the scopes from this installation's own catalogue, and the PKCE challenge, and receives the single-use code the app will exchange. The consent is recorded as a grant the person can see and revoke beside their sessions; the web application's consent screen calls exactly this. A public client without PKCE is refused; S256 is the only accepted method - plain would put the verifier on the wire twice.

The token endpoint. Public the way sign-in is: what authenticates is in the body - the single-use code, the PKCE verifier whose S256 hash has to equal the challenge the code was minted under, and, for a confidential client, the secret. A code replayed after exchange is refused; the redirect URI has to repeat the authorization's, exactly. The answer is the same pair sign-in mints, leashed to the grant: revoking the grant refuses the pair on its next request, exactly as refresh reuse would. Refresh happens at /auth/sessions:refresh, because it is the same machinery. The body is JSON; the form encoding of RFC 6749 is not accepted.

One's own grants, newest first: which client, which scopes, when it was allowed and when it last acted. Never anybody else's - what a person allowed is theirs to see and to withdraw, the session listing's reasoning.

Immediate: every session the grant leashed refuses on its next request, the way a revoked session's pair does. Somebody else's grant is not found rather than forbidden; revoking twice is not an error.