Add AgentID to Supabase

In the Supabase dashboard, open Authentication and pick Sign In / Providers. Older write-ups call it Authentication → Providers; the entry has been renamed.

Scroll past the built-in social logins to the Custom Providers panel, then New Provider. It is a separate list, so an empty table here does not mean your other providers are gone.

The create form prints your project callback URL at the bottom, next to a copy button. Take it now, because the next step needs it. It is a property of the project rather than of this provider, so it is the same value whatever you end up naming things: https://your-project.supabase.co/auth/v1/callback.

Leave this form open. You will fill the rest of it in step 5, once the console has given you a client to point it at.

In the AgentID console, register an application using the callback URL you just copied.

Enter an app name and paste the callback URL from step 2 as the single redirect URI. AgentID generates the client id and uses client_secret_basic automatically.

Scope selection happens in Supabase in step 5, not during AgentID registration.

The client_secret is shown once and never again. Copy it before you close the dialog; closing without it means registering a new client, since there is no way to reveal this one again.

Back in the Supabase form. The identifier field has a fixed custom: prefix that is not yours to type, so you supply only the suffix: agentid gives you the provider custom:agentid that your code will name.

Keep Auto-discovery selected and give it the issuer. The discovery URL below it can stay empty, since AgentID serves discovery at the standard path. Then paste the client ID and secret from the console.

Provider Identifier   custom: agentid
Display Name          AgentID
Configuration Method  Auto-discovery
Issuer URL            https://auth.agentid.com
Discovery URL         (leave empty)
Client ID             <client_id from step 3>
Client Secret         <client_secret from step 4>
Scopes                openid, email, profile

Watch out. Leave Allow users without email off. It exists for providers that return no address at all, and AgentID always returns one when email is granted, so turning it on only widens what your project accepts without gaining you anything.

Scopes is the row people skip, and it is the only scope choice you need to make. A request naming no scopes falls back to openid and email, so leaving the field as Supabase suggests can hand you a bare token. Enter scopes comma-separated here, not space-delimited as on the wire.

Watch out. Add owner_profile and owner_email only if your app needs the human owner’s identity. When requested, the agent’s signing credential must still permit them.

Create and enable provider saves and switches it on in one go, and discovery runs at that moment. The provider then shows in the list as an OIDC provider, enabled, under the identifier your code passes.

await supabase.auth.signInWithOAuth({ provider: 'custom:agentid' })

The agent approves the request out of band, so the browser waits rather than showing a password form. What the agent has to do is on approving a sign-in.

Watch out. PKCE is on by default in Supabase and needs no configuration, which is one less thing to get wrong than elsewhere. Free projects are capped at three custom providers. Owner information does not reach the Supabase user record: those claims are served from /userinfo, so read them there with the access token rather than expecting them on the session user.