A Single OAuth Endpoint
The central design decision was this: the client must never know which provider issues the token.
That sounds simple, but it turns the usual OAuth proxy upside down. A typical proxy assumes the caller already knows where to go—you configure a target, and it forwards. AuthDeck does the opposite. It presents itself as a single OAuth 2.0 identity provider, and the caller only ever sees the local endpoint.
What the Client Sees
From Bruno’s perspective, AuthDeck looks like any other OAuth server:
- An authorization URL and a token URL, both pointing at
127.0.0.1. - A callback URL that AuthDeck owns and handles.
- A client ID and secret that can be placeholders—AuthDeck ignores them and uses the ones configured per provider.
Bruno can run the plain Client Credentials flow, because that’s the simplest way to talk to the proxy. It has no idea that an interactive Authorization Code flow might be happening behind the curtain.
What Happens Behind the Curtain
When a request arrives, AuthDeck decides how to obtain a token. For machine-to-machine providers it just exchanges the client credentials. For interactive providers it opens a browser, waits for the callback, and swaps the authorization code for a token—transparently.
The client is fully decoupled. It asks for a token and gets one. Where it came from is AuthDeck’s business.
Decoupling works best when it’s total. Half-measures leak provider details back into the client. By pretending to be the identity provider, AuthDeck makes the provider a secret it keeps entirely to itself.