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.

By Kevin O'Connor

Published Last reviewed 6 min read

An OAuth issuer is an exact identifier. Treating it as an approximate hostname is a small implementation shortcut with a large security consequence: the client can end up sending credentials to endpoints it never intended to trust.

RFC 8414 describes an OAuth authorization server. OpenID Connect Discovery 1.0, incorporating errata set 2 describes an OpenID Provider and its identity capabilities. Their fields overlap, but their URL construction and validation requirements need separate handling.

I would start an agent integration by identifying how it obtains the expected issuer, then follow that identifier through discovery and the authorization response. Inferring a token URL from the product's home page isn't a trust model.

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

For a path issuer such as https://id.example/tenant-a, OpenID Connect appends the discovery suffix after the issuer path: https://id.example/tenant-a/.well-known/openid-configuration. RFC 8414 puts its suffix before that path. A client library needs fixtures for both transformations, including trailing slashes and encoded path components. Swapping suffixes in one hard-coded URL template won't produce both results correctly.

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.

A useful negative fixture is a response with correct-looking endpoints and an issuer that differs only by a trailing slash. Exact issuer comparison should reject it; URL normalization mustn't repair an identity mismatch. Include a case where an unexpected jwks_uri points to a local address, too. Backend retrieval must stop before the fetch, even when the metadata parses correctly.

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.

A separate TARE authorization service would need 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 on the provider that implements the identity semantics and validation rules, including when a hosted provider supplies them. This article does not audit TARE's separate authentication implementation.

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.