Endpoints

The pages here describe each endpoint on its own, as a reference you can open while you write or debug a client. Each has the same shape: the request, what the answer contains, the errors and what they mean, a worked example and the security notes. They are for developers who already know which flow they are in and need the exact rules of one call.

If you want the story of a sign-in from start to finish, read Flows first. These pages are the other direction: the same calls, one at a time.

Only one address is configured: the issuer. Discovery publishes the rest. A sign-in uses the pushed authorization, authorize and token endpoints in that order. The other endpoints serve what happens afterwards: reading the profile, checking a token, revoking it, ending the session, fetching the keys that verify it, and, for a service, asking what a person may do.

configure:   issuer -> discoverysign in:     PAR -> authorize (browser) -> tokenafterwards:  userinfo | introspection | revocation | end sessionverify:      JWKS (keys)decide:      authorization decision API (a service asks)

I am wiring a client by hand.

1. Discovery: read the endpoints from one document.
2. Pushed authorization requests: push the request.
3. Authorize: send the browser.
4. Token: redeem the code.

I am verifying tokens in an API.

1. JWKS and key rotation: fetch and cache the keys.
2. Introspection: check a token that must reflect revocation.
3. Userinfo: read the profile claims.

I am signing a person out.

1. End session: send the browser to identity.
2. Revocation: revoke the tokens you hold.

Discovery answers what the discovery document publishes, how to cache it and which checks a client must make against it. JWKS and key rotation answers how to fetch the public keys, cache them correctly and keep verifying through a rotation without a deploy: a retired key stays published after it stops signing.

Pushed authorization requests answers what to push and what comes back, a short-lived reference that is the only thing the browser carries. Authorize answers how to send the browser with the reference, what the person sees, and what your callback must check. Token answers the rules every grant shares and each of the four grants, client authentication, DPoP, the response members and the errors.

Userinfo answers how to read profile claims with an access token and what it refuses. Introspection answers whether a token is usable right now, which a locally verified JWT cannot say, and who may ask about which token. Revocation answers how to revoke a refresh token or an access token your client holds. End session answers how to end the person's sign-in session and get them back to your application.

Authorization decision API answers how a service asks whether a person may perform an action, one question or up to 200 at a time. It is Available: the endpoints answer a correctly authenticated service, and a product is onboarded to them by TDACorp.

A registered client and the issuer address. Read Client authentication before the endpoints that need it, and DPoP before the token endpoint.

Which address do I configure? Only the issuer. See Environments and the issuer.

Can a request go straight to authorize? No. The pushed request is mandatory. See Authorize.

Does verifying a JWT see a revocation? No. Use introspection when that matters. See Introspection.

How do I survive a key rotation? Cache the keys and refetch on an unknown key id. See JWKS and key rotation.

Which grants does the token endpoint serve? Four. See Token.

It does not cover the account API under /v1/me, which is in the Reference. It does not describe the private browser sign-in requests. Generated tables of endpoints and error codes are in the Reference, and refusals are explained in Troubleshooting.