GET /.well-known/oauth-authorization-server

2 min read

GETHTTP method

NoneAuth

publicRing

Endpoint

Method	`GET`
Path	`/.well-known/oauth-authorization-server`
Ring	public (OAuth metadata)

Parameters

None. A discovery read.

Response

A JSON metadata document per RFC 8414: the token_endpoint, jwks_uri, introspection_endpoint, supported grant types (client_credentials), scopes and signing algorithms. Point an OAuth library at the base URL and it can read this to configure the whole flow without hard-coded URLs. It is the discovery anchor for client-credentials auth.

Errors

Cacheable and public. A 429 applies only under extreme load.

Using it in practice

Most OAuth client libraries can bootstrap from this one document: point the library at the Credicorp base URL, let it fetch the metadata, and it discovers the token endpoint, JWKS URI and supported grants automatically — no hard-coded URLs to drift. This matters because it means a future change to, say, the JWKS location flows to your client without a code change, provided you configured from the metadata rather than pinning the URL directly. Cache the document and refresh it periodically.

Frequently asked questions

What is this document for?

Auto-configuration. An OAuth client reads it to discover the token endpoint, JWKS URI and supported grants, so you do not hard-code those URLs — you point your library at the metadata and it wires itself up.

Is it the same as the protected-resource document?

No. This describes the authorization server (where tokens come from). The oauth-protected-resource document describes a resource server (like the partner MCP) and points back at this one.

How often should I fetch the metadata?

Fetch it on start-up and cache it, refreshing periodically (for example daily). It changes rarely, but reading it rather than hard-coding the endpoints means an infrastructure change reaches your client automatically.