Sign in with The Revelation Standard

For developers · OpenID Connect

Let people sign in to your app with their The Revelation Standard account. It is standard OpenID Connect – the same thing behind "Sign in with Google" – so if your framework already speaks OIDC, you point it at one URL and you are done.

No application, no approval, no fee. Registration is automatic, which is the whole point of the section below.

1. The only URL you need

https://trsd.therevelationstandard.workers.dev/.well-known/openid-configuration

Most OIDC libraries take that single address and configure themselves from it. If yours does, skip to step 3.

2. Register your app (automatic)

There is no form to fill in and nobody to email. Your app registers itself with one request – this is Dynamic Client Registration:

curl -X POST https://trsd.therevelationstandard.workers.dev/mcp/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "Your App",
    "redirect_uris": ["https://yourapp.com/callback"]
  }'

You get back a client_id. Keep it. There is no client secret, because there does not need to be one – see step 3.

3. Send them to sign in

Authorization Code flow with PKCE, which is the current default for web, mobile and single-page apps. PKCE is required here, and it is why no client secret exists: the proof travels with the request instead of being a permanent password your app has to hide.

https://trsd.therevelationstandard.workers.dev/mcp/authorize
  ?client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.com/callback
  &response_type=code
  &code_challenge=BASE64URL_SHA256_OF_YOUR_VERIFIER
  &code_challenge_method=S256
  &state=YOUR_RANDOM_STATE

The person picks how they want to prove who they are – Apple, Google, Microsoft, GitHub and others, or as a guest. That is our problem, not yours. They come back to your redirect_uri with ?code=…&state=….

4. Swap the code for a token

curl -X POST https://trsd.therevelationstandard.workers.dev/mcp/token \
  -d grant_type=authorization_code \
  -d code=THE_CODE \
  -d client_id=YOUR_CLIENT_ID \
  -d redirect_uri=https://yourapp.com/callback \
  -d code_verifier=YOUR_ORIGINAL_VERIFIER

The code is single‑use and expires in five minutes.

5. Find out who they are

curl https://trsd.therevelationstandard.workers.dev/oauth/userinfo \
  -H "Authorization: Bearer THE_ACCESS_TOKEN"

{
  "sub":   "9fd8a2a8-e052-4a3a-94a5-9781d123a22f",
  "email": "them@example.com",
  "name":  "Their Name"
}

Key your accounts on sub, never on the email

This is the one thing worth getting right. sub is a permanent identifier that belongs to that person forever. An email address can change hands – people abandon addresses, companies recycle them – so an app that treats the email as the identity can hand someone's account to a stranger who later gets that address. Store sub. Treat email as a display detail that may change.

Reference

Implicit flow and the password grant are not supported. Both are considered obsolete, and neither is coming.

The button

Label it "Continue with The Revelation Standard". Please do not restyle our name or imply we endorse your app – use it to say truthfully that people can sign in with their account here.

Questions

Email FounderandCEO@TheRevelationStandard.Com. A real person answers.