TKOResearch
Menu
Back to insights
AI InfrastructureAgent-Readable WebImplementation guide

OAuth and OpenID Connect Discovery for AI Agents

How agents distinguish OAuth authorization-server metadata from OpenID Provider configuration and reject invented issuers or endpoints.

Last reviewed July 16, 20265 min read

OAuth authorization-server metadata and OpenID Provider configuration share fields and use well-known URLs. They still describe different protocol roles.

RFC 8414 tells an OAuth client how an authorization server is configured. OpenID Connect Discovery 1.0 tells an OpenID Connect Relying Party how an identity provider is configured. An agent that treats either document as generic login instructions can select the wrong issuer, endpoint, grant, or identity behavior.

Discovery starts from an issuer the client already trusts through configuration or a protocol-defined process. It does not start by guessing token endpoints from a site's hostname.

RFC 8414 describes an authorization server

The default OAuth metadata suffix is oauth-authorization-server. For the issuer https://auth.example, a client requests:

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: auth.example

The JSON response has a required issuer value. Depending on supported grants, it can identify authorization_endpoint and token_endpoint. It may also publish jwks_uri, registration_endpoint, supported scopes, response types, response modes, grant types, token-endpoint authentication methods, revocation, introspection, and other registered metadata.

These fields are configuration, not permission. Advertising scopes_supported doesn't grant a client every listed scope. Naming a registration endpoint doesn't promise open registration. The client still follows the server's policy and the applicable OAuth profile.

The issuer check is central. RFC 8414 requires the returned issuer to be identical to the issuer used to construct the metadata request. A client must reject a mismatch rather than follow the response's endpoints. That comparison binds the configured issuer to the metadata document and reduces authorization-server mix-up and impersonation risk.

Issuer identifiers can include a path. In that case, RFC 8414 inserts /.well-known/{suffix} between the host and issuer path. For an issuer such as https://example.com/tenant-a, the default metadata location becomes:

https://example.com/.well-known/oauth-authorization-server/tenant-a

Use a tested URI implementation. String concatenation commonly puts the suffix in the wrong place or loses percent-encoding rules.

OpenID Connect Discovery adds identity metadata

OpenID Connect is an identity layer built on OAuth 2.0. Its Provider Configuration document uses the openid-configuration suffix and includes OAuth endpoint data, which explains the visual overlap with RFC 8414.

An OpenID Provider also publishes identity-specific fields. Examples include userinfo_endpoint, supported subject identifier types, ID Token signing algorithms, claims, and OpenID Connect request capabilities. A Relying Party uses those values to validate authentication responses and identity claims.

For a root issuer, the familiar location is:

https://id.example/.well-known/openid-configuration

OpenID Connect Discovery and RFC 8414 differ in their historical path transformation for issuers containing a path. RFC 8414 documents that compatibility point and recommends its transformation for OAuth authorization-server metadata going forward. A client library needs protocol-specific tests for non-root issuers; swapping suffixes is not sufficient.

An OAuth-only authorization server should not claim OpenID Provider behavior. It may have no ID Tokens, UserInfo endpoint, or subject identifier model. Conversely, an OpenID Connect client must validate the identity-layer fields its selected flow requires rather than assuming every OAuth metadata response supports authentication.

Metadata requirements also depend on the selected flow. authorization_endpoint is required by RFC 8414 unless the server supports no grant that uses it. token_endpoint has its own condition. response_types_supported is required, while fields such as registration_endpoint and jwks_uri are optional at the RFC 8414 layer. A generic presence check that demands every familiar field will reject valid deployments; a check that accepts any JSON object will miss incomplete ones. Validate against the client profile and selected grant.

OpenID Connect adds stricter needs for ID Token processing. A Relying Party must select an advertised signing algorithm permitted by its policy, retrieve the correct keys, verify issuer and audience claims, check time claims and nonce where required, and bind the authentication response to the initiating session. Discovery supplies inputs to those checks. It doesn't perform them.

Signed authorization-server metadata is an optional RFC 8414 feature. When supported, its JWT can protect metadata values beyond the HTTPS channel, and the RFC defines precedence for values carried inside it. A client that doesn't implement signed metadata may ignore that member. It must never treat an unverified JWT as stronger configuration.

Endpoint guessing breaks the issuer relationship

Consider a client given https://login.example. Guessing https://login.example/authorize, /token, and /jwks.json produces plausible URLs with no protocol assurance that they belong together. A deployment could host tenants on paths, keep keys under a different host, omit the authorization endpoint for its grants, or use mutual TLS aliases.

Accepting a metadata response for https://login.example whose issuer is https://attacker.example is worse. The client may send an authorization code, client assertion, or credential to endpoints selected by another authority.

The validation order should be explicit:

  1. Obtain the expected issuer from trusted configuration or the protocol's issuer-discovery procedure.
  2. Build the correct well-known URL for the chosen OAuth or OpenID Connect metadata type.
  3. Fetch over HTTPS with bounded redirects, response size, timeouts, and address resolution.
  4. Compare the returned issuer exactly with the expected value.
  5. Validate every required endpoint, supported grant, algorithm, and client authentication method before starting authorization.

Redirects deserve special care. Revalidate scheme, host policy, and public address after every hop. Metadata retrieval from a backend can become a server-side request forgery path if an untrusted party controls the issuer. Client applications should allow only issuers established through their onboarding model.

Keys also have a lifecycle. Cache the JWK Set according to HTTP policy, handle rotation without accepting an unknown issuer, and constrain algorithms to the profile. A jwks_uri is a location, not a reason to trust every key or algorithm found there.

RFC 9700, the OAuth 2.0 Security Best Current Practice, recommends publishing and using authorization-server metadata. It also provides the broader protections for redirect URIs, code flows, sender constraints, and client behavior that discovery alone cannot supply.

Discovery metadata follows the deployed service

The public TKOResearch site does not operate an OAuth authorization server or OpenID Provider. A navigation label, contact workflow, or application session would not create those roles. Publishing well-known JSON with invented endpoints would advertise token and identity behavior that production cannot perform.

If TARE introduces an authorization service, the launch needs one canonical issuer per security domain, production endpoints, key custody and rotation, defined client registration, least-privilege scopes, tenant isolation, revocation, monitoring, and tested metadata. OpenID Provider configuration belongs only where TARE also implements the identity semantics and validation rules.

Until those services exist, a 404 at the discovery locations is accurate. Missing optional authorization metadata on a site without an authorization server is not a site defect.