Sign in AI agents

There is no revocation endpoint: a person revokes an agent in EndPointBlank.

Redirect URIs are compared byte for byte: no case folding, no trailing slash, no default port. The one exception is a loopback URI (127.0.0.1, [::1] or localhost), which also matches the same URI on any port, so a native agent can listen on whatever port it gets. Only the port may differ: localhost does not match 127.0.0.1, and the path and query must be identical.

The verifier is 43 to 128 unreserved characters (RFC 7636). With openssl:

CODE_VERIFIER=$(openssl rand -base64 48 | tr -d '\n=' | tr '+/' '-_')
CODE_CHALLENGE=$(printf '%s' "$CODE_VERIFIER" \
  | openssl dgst -sha256 -binary | openssl base64 -A | tr -d '=' | tr '+/' '-_')

On approval the browser comes back to your redirect URI with code, your state and iss. Check that state is the one you sent and iss is the issuer above before you use the code. The code works once, for sixty seconds.

An unknown client_id, or a redirect_uri the client did not register, is shown to the person as an error page and never redirected. So are three refusals after sign-in: an organization with no access to the provider (403), an organization without a slug (409) and EndPointBlank staff impersonating an organization (403). The person sees a page and your agent hears nothing. Every other error goes to your redirect URI as error and error_description, with iss, and with your state unless it was over 1,000 bytes or not a string, in which case state is left out.

• Any member of the organization may approve, as one of the applications they can see (the same rule as the Applications pages). A member in no group sees none.
• The organization must already have access to the provider: an internal grant within one organization, or across organizations an accepted client invite with access to the provider's application. Without it the page says so, nothing can be approved, and nothing is sent to the agent.
• One exception: when the provider has invited the person's email address to be its client (the account invite POST /api/v1/clients sends to an existing EndPointBlank user) with access to this API, the page shows that request instead. An organization admin approves by accepting it, choosing an existing application or creating one to act as, in one step: the invite is accepted, its packages and grants applied, the application linked to the provider and the agent approved. A member who is not an admin is asked to get one.
• An organization a provider manages for a customer has no members. Its owner signs in instead with a one-time code emailed to the address the provider set (owner_email on POST /api/v1/clients or PATCH /api/v1/clients/:id), without claiming it, and may approve any of its applications with access. A PATCH that changes the address revokes every agent the old address approved. Once the customer claims the organization, its admins see the owner's agents on the connected-agents page and may revoke them.
• EndPointBlank staff impersonating an organization cannot approve, and an organization without a slug cannot connect agents.
• Deny sends error=access_denied to your redirect URI.

The answer is access_token, token_type Bearer, expires_in in seconds and refresh_token, with no scope. Every answer carries Cache-Control: no-store. A code refused with invalid_grant, or sent with a valid resource other than the one it was issued for, is spent all the same: start the sign-in again. A request refused before the code is looked at (invalid_request, invalid_client, or a resource that is not a base URL) leaves the code as it was. Send the access token to the provider's API as Authorization: Bearer.

A refresh token works once. Presenting a spent one again revokes every refresh token of that sign-in, the one just issued from it included, however soon after and from whichever client. The agent can no longer refresh, and the person has to approve it again. The sign-in itself is not revoked: the access tokens already issued live out their hour. So:

• Never send two refreshes of one token at once. Serialize them across every process that shares the token, and store the new refresh token before you use the new access token.
• Do not resend a refresh whose answer you lost: to EndPointBlank it looks the same as a stolen token used twice.
• After temporarily_unavailable (503), sending the same code or refresh token again is safe: nothing was spent.

An authorization code presented a second time revokes that sign-in's refresh tokens too.

GET https://api.provider.example/.well-known/oauth-protected-resource/mcp

{
  "resource": "https://api.provider.example/mcp",
  "authorization_servers": ["https://app.endpointblank.com"]
}