Discovery
The discovery document, what it publishes, how to cache it and which checks a client must make against it.
On this page
Discovery is the one address you configure. The discovery document lists every endpoint, the grants, authentication methods, signing algorithms and scopes that identity supports, so a client reads them instead of hard-coding paths.
Request#
curl -s https://identity.tdacorp.in/.well-known/openid-configurationThe same document is also served at /.well-known/oauth-authorization-server, the name RFC 8414 uses, so a library that looks for either finds it.
| Property | Value |
|---|---|
| Method | GET, no authentication |
| Parameters | None |
| Response | 200 with application/json |
Cache-Control | public, max-age=60, s-maxage=300, stale-while-revalidate=300 |
| CORS | Access-Control-Allow-Origin: *, so a browser application can read it |
Response members#
The response is one JSON object. These members are published.
| Member | Value |
|---|---|
issuer | The issuer identifier. It has no trailing slash. |
authorization_endpoint, pushed_authorization_request_endpoint, token_endpoint, userinfo_endpoint, introspection_endpoint, revocation_endpoint, end_session_endpoint, jwks_uri | Absolute addresses built from the issuer. Each is described in this section. |
response_types_supported | ["code"] |
response_modes_supported | ["query", "form_post"] |
grant_types_supported | authorization_code, refresh_token, client_credentials and urn:ietf:params:oauth:grant-type:token-exchange |
code_challenge_methods_supported | ["S256"] |
token_endpoint_auth_methods_supported | private_key_jwt and none. The introspection and revocation endpoints publish the same list under their own members. |
token_endpoint_auth_signing_alg_values_supported | EdDSA, ES256 |
id_token_signing_alg_values_supported | EdDSA, ES256 |
dpop_signing_alg_values_supported | EdDSA, ES256 |
subject_types_supported | public, pairwise. A client is public unless it was registered pairwise; a pairwise client sees a different sub per sector, in its ID token, userinfo response and back-channel logout token. |
scopes_supported | openid, profile, email, offline_access, tdaid.tenant |
claims_supported | The claim names listed in the claims reference |
acr_values_supported | aal1, aal2, aal3 |
backchannel_logout_supported, backchannel_logout_session_supported | true |
authorization_response_iss_parameter_supported | true |
resource_indicators_supported | true |
require_pushed_authorization_requests | true: every authorization request is pushed first |
authorization_details_types_supported | tdaid:agent_action, tdaid:elevation |
device_authorization_endpoint | null. The device grant is deliberately not offered. |
The generated OIDC endpoints page lists the same table from the capability source.
A member is published only when what it describes is reachable. CIBA, with its /bc-authorize address, is not available, so it has no member. Client-certificate authentication (tls_client_auth) and certificate-bound tokens are listed only on a deployment that has mutual TLS switched on; do not rely on them being present.
Worked example#
{ "issuer": "https://identity.tdacorp.in", "authorization_endpoint": "https://identity.tdacorp.in/authorize", "pushed_authorization_request_endpoint": "https://identity.tdacorp.in/par", "token_endpoint": "https://identity.tdacorp.in/token", "userinfo_endpoint": "https://identity.tdacorp.in/userinfo", "jwks_uri": "https://identity.tdacorp.in/.well-known/jwks.json", "response_types_supported": ["code"], "code_challenge_methods_supported": ["S256"], "require_pushed_authorization_requests": true, "device_authorization_endpoint": null}The example is shortened to the members a login needs.
Errors#
The document has no parameters, so it has no OAuth errors. A server fault returns a 5xx problem response. Treat any non-200 as a failure to configure and retry later; do not fall back to guessed addresses.
Security notes#
- Compare the issuer exactly. The
issuervalue must equal, byte for byte, the issuer you configured, and theissof every token and every authorization response. A trailing slash is a different issuer. The SDK refuses a document whose issuer differs. - Take every address from the document, and refuse an endpoint that is not on the issuer you trust. Do not let a value you read from an untrusted place choose where a client assertion or a code is sent.
- Cache it yourself. The response is cacheable for a short time (one minute in a browser, five at a shared cache, so an edge copy can lag a change by several minutes), and identity can add members over time. The SDK keeps its copy for five minutes. A client that fetches on every request adds load for no gain; one that never refreshes misses changes.
- Algorithms are an allow-list you own. The document lists what identity can sign with. Verify ID tokens and access tokens only with algorithms you chose, never with whatever the token header names. The SDK defaults to
EdDSAonly.