How It Works

What Fake ID does (and doesn't do)

The OIDC Flow

Typically, if you are authenticating users to your application via OIDC, you would have an OP — an OIDC provider — running somewhere. Upon hitting, for instance, a "login with OIDC" button, your app would redirect the user to the OP, wherein they would log in and be presented with a consent page saying what application needed access, and a button to grant that. Once they grant those permissions, they're redirected back to your application, which, depending on the flow used, would either get an id token immediately, or proceed to obtain one via the back channel.

What Fake ID aims to provide is that same functionality for development, without the bother of having to run a full blown OP, and without the need for any user interaction. The relying party — that's your application — will simply run off to Fake ID, and everything happens automatically, giving it back an id token which it can then use.

Implemented Endpoints

/.well-known/openid-configuration

Discovery endpoint. Prevents clients having to be configured with various other endpoints.

/authorize

Where the initial authorisation request goes. Automatically redirects back to the relying party with state, an auth code, and any requested tokens.

/token

Where the relying party can exchange an auth code for access and id tokens.

/jwks

Where the public key used to sign the id tokens is available, so relying parties can verify id tokens.

/userinfo

Returns the configured claims in JSON format.

What Fake ID Does NOT Do

Fake ID is just that — fake. It does not authenticate, nor is it even currently aware of, OAuth clients. You must include a client_id in requests and a client_secret for token requests. These must merely be present; they aren't checked at all.

The id token returned will always contain the same claims (exp and iat aside).

In short: this is not, in any way, an actual implementation of OIDC. It should go without saying — this must not be used to secure anything which matters.