You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(transport): bearer transport mode for the auth proxy #163
#147 (PR #162) lets an adopter's own routes accept the auth API's access token as a bearer credential. That is half of what a native client needs. The other half is obtaining and refreshing that token through the adapter, because in a typical deployment the auth API is private and only the adapter reaches it, and the adapter owns email delivery (external delivery mode, adopter templates), client IP forwarding, and the service token. A native client that talked to the auth API directly would bypass all three and need the auth API exposed.
Today every proxied /auth/* route assumes cookies: checkProxyIdentity reads identity from cookies, buildServiceAuthorization takes the inner token from the cookie payload, respond mints cookie wrappers and strips tokens from the body, and ensureCookies does the silent refresh. There is no /auth/refresh route.
Scope
A request that carries x-seamless-auth-transport: bearer is served in bearer mode:
The client's Authorization header is forwarded to the auth API verbatim (ephemeral token on pre-auth routes, access token on access routes). checkProxyIdentity is skipped; a route that needs an identity and gets no Authorization answers 401 missing_token.
The upstream JSON body passes through unchanged, tokens included. No cookies are set or cleared.
ensureCookies is skipped.
POST /auth/refresh is added: Authorization: Bearer <refresh token> in, the rotated pair out, via the existing refreshAccessToken in core with the service token attached.
Cookie mode is unchanged byte for byte. originGuard stays as it is (inert without Origin / Sec-Fetch-Site).
Express and Fastify, with the parity suite covering both modes.
Notes
Messaging (external delivery) and forwarded client IP / user agent work exactly as in cookie mode, since they are attached by the proxy regardless of transport.
The header, rather than the presence of Authorization, selects the mode because the first request of a flow (/login, /registration/register) carries no token.
Activity
feat(transport): serve a bearer transport on the auth routes and add …