Exchange credentials for a TEA access token

Exchange credentials for a TEA access token.

A TEA server that requires authentication on any of its endpoints shall implement this endpoint, and shall support the client_credentials grant type with HTTP Basic client authentication (RFC 6749 section 2.3.1, RFC 7617): the API key identifier is sent as the user-id and the API key secret as the password. A server that requires no authentication need not implement it.

Clients do not probe this endpoint to discover whether authentication is required: they issue the resource request, and a 401 response carrying a WWW-Authenticate: Bearer challenge is the signal to obtain a token here. A 404 from this endpoint, with or without a TEA error body, means only that it is not implemented. A server that mounts the path without implementing the exchange should answer with the shared object-not-found response and error: NOT_IMPLEMENTED.

Servers may support additional grant types for federated identity, for example SAML 2.0 assertions (RFC 7522) or JWT assertions (RFC 7523), and may authenticate the client with mutual TLS (RFC 8705) instead of Basic. Whichever grant type is used, the token returned by this endpoint is the only credential accepted on the other TEA endpoints.

RFC 8693 token exchange (urn:ietf:params:oauth:grant-type:token-exchange) is outside the scope of the TEA 1.0 interoperable authentication profile. TEA 1.0 does not specify the request or response contract for this grant. Implementations may support it as an extension by separate agreement, but clients shall not assume its availability based solely on TEA 1.0 conformance. Such extensions do not remove the requirement for servers requiring authentication to support the client_credentials baseline.

The access token is opaque to the client: clients shall not inspect, parse, or depend on its contents.

The empty security requirement on this operation does not authorize anonymous client_credentials issuance. It only allows the alternate client-authentication methods described above (for example, mutual TLS, JWT client assertion (RFC 7523), or credentials in the request body). For the baseline client_credentials grant with HTTP Basic, unauthenticated requests shall not be accepted: servers shall respond with 401, error: invalid_client, and a WWW-Authenticate: Basic challenge (see 401-token-error; RFC 6749 section 5.2).