shebang!

Sign in with sherlock (redirect)

The full OAuth 2.1 / OIDC flow for letting another app authenticate against a shebang account.

Sign in with sherlock (redirect)

Send a user to sherlock to sign in, and get them back with tokens — no password form lives in your app, and a user already signed in to one shebang-backed app is signed in to every other app on the same sherlock account.

1. Register a client

Dynamic client registration, against the discovery document at https://auth.shebang.pro/auth/v1/.well-known/openid-configuration:

curl -X POST https://auth.shebang.pro/auth/v1/oauth/clients/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "My app",
    "redirect_uris": ["https://myapp.example.com/callback"],
    "token_endpoint_auth_method": "none"
  }'

token_endpoint_auth_method: "none" registers a public client (a browser app or CLI, with no secret to protect). Use "client_secret_post" instead for a confidential client — a server that can hold one — and the response includes a client_secret.

2. Send the user to the authorize URL

With a PKCE challenge (S256 only — plain isn't supported) and a state value you'll check on the way back:

https://auth.shebang.pro/auth/v1/oauth/authorize
  ?response_type=code
  &client_id=<client_id>
  &redirect_uri=<redirect_uri>
  &scope=openid email profile
  &code_challenge=<S256 challenge>
  &code_challenge_method=S256
  &state=<random state>

The consent screen the user sees names your app and lists these scopes.

3. Handle the callback

At your redirect_uri (?code=...&state=...), check state matches what you sent, then exchange the code for tokens:

curl -X POST https://auth.shebang.pro/auth/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=authorization_code" \
  --data-urlencode "code=<code>" \
  --data-urlencode "redirect_uri=<redirect_uri>" \
  --data-urlencode "client_id=<client_id>" \
  --data-urlencode "code_verifier=<verifier>"

You get back access_token, refresh_token, and id_token (a JWT carrying the user's email and sub). The access_token is a sherlock user JWT (aud: "authenticated") — pass it as a Bearer token to your database's Data API, or to api.shebang.pro, and either accepts it as that signed-in user.

4. Use the token with supabase-js

So row-level security sees the signed-in user:

const supabase = createClient(api_url, publishable_key, {
  global: { headers: { Authorization: `Bearer ${access_token}` } },
});

5. Refresh

curl -X POST https://auth.shebang.pro/auth/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=refresh_token" \
  --data-urlencode "refresh_token=<refresh_token>" \
  --data-urlencode "client_id=<client_id>"

6. Log out

Drop the tokens client-side — sherlock sessions end with sign-out- everywhere, not a per-app revoke.

For a complete, runnable version of this flow, see the sign-in-with-sherlock guide.

Next

Account management.