Process Federation Registration Request
The Authlete API is for implementations of the federation registration
endpoint that accepts “explicit client registration”. Its details are
defined in OpenID Connect Federation 1.0.
The endpoint accepts POST requests whose Content-Type
is either of the following.
application/entity-statement+jwt-application/trust-chain+jsonWhen theContent-Typeof a request isapplication/entity-statement+jwt, the content of the request is the entity configuration of a relying party that is to be registered. In this case, the implementation of the federation registration endpoint should call Authlete’s/federation/registrationAPI with the entity configuration set to theentityConfigurationrequest parameter. On the other hand, when theContent-Typeof a request isapplication/trust-chain+json, the content of the request is a JSON array that contains entity statements in JWT format. The sequence of the entity statements composes the trust chain of a relying party that is to be registered. In this case, the implementation of the federation registration endpoint should call Authlete’s/federation/registrationAPI with the trust chain set to thetrustChainrequest parameter.
Documentation Index
Fetch the complete documentation index at: https://developers.authlete.com/llms.txt
Use this file to discover all available pages before exploring further.
Authorizations
Authenticate every request with a Service Access Token or Organization Token.
Set the token value in the Authorization: Bearer <token> header.
Service Access Token: Scoped to a single service. Use when automating service-level configuration or runtime flows.
Organization Token: Scoped to the organization; inherits permissions across services. Use for org-wide automation or when managing multiple services programmatically.
Both token types are issued by the Authlete console or provisioning APIs.
Path Parameters
A service ID.
Body
Response
The code which represents the result of the API call.
A short message which explains the result of the API call.
The next action that the authorization server implementation should take.
OK, BAD_REQUEST, NOT_FOUND, INTERNAL_SERVER_ERROR The content that the authorization server implementation can use as the value of WWW-Authenticate
header on errors.
{
"number": 1140735077,
"serviceNumber": 715948317,
"clientName": "My Test Client",
"clientId": "1140735077",
"clientSecret": "gXz97ISgLs4HuXwOZWch8GEmgL4YMvUJwu3er_kDVVGcA0UOhA9avLPbEmoeZdagi9yC_-tEiT2BdRyH9dbrQQ",
"clientType": "PUBLIC",
"redirectUris": ["https://example.com/callback"],
"responseTypes": ["CODE"],
"grantTypes": ["AUTHORIZATION_CODE"]
}