Authlete CIBA API
API endpoints for implementing Client-Initiated Backchannel Authentication (CIBA).
OpenAPI Specification
openapi: 3.0.3
info:
title: Authlete Authorization Endpoint CIBA API
description: "Welcome to the **Authlete API documentation**. Authlete is an **API-first service** where every aspect of the \nplatform is configurable via API. This documentation will help you authenticate and integrate with Authlete to \nbuild powerful OAuth 2.0 and OpenID Connect servers.\n\nAt a high level, the Authlete API is grouped into two categories:\n\n- **Management APIs**: Enable you to manage services and clients.\n- **Runtime APIs**: Allow you to build your own Authorization Servers or Verifiable Credential (VC) issuers.\n\n## \U0001F310 API Servers\n\nAuthlete is a global service with clusters available in multiple regions across the world:\n\n- \U0001F1FA\U0001F1F8 **US**: `https://us.authlete.com`\n- \U0001F1EF\U0001F1F5 **Japan**: `https://jp.authlete.com`\n- \U0001F1EA\U0001F1FA **Europe**: `https://eu.authlete.com`\n- \U0001F1E7\U0001F1F7 **Brazil**: `https://br.authlete.com`\n\nOur customers can host their data in the region that best meets their requirements.\n\n## \U0001F511 Authentication\n\nAll API endpoints are secured using **Bearer token authentication**. You must include an access token in every request:\n\n```\nAuthorization: Bearer YOUR_ACCESS_TOKEN\n```\n\n### Getting Your Access Token\n\nAuthlete supports two types of access tokens:\n\n**Service Access Token** - Scoped to a single service (authorization server instance)\n\n1. Log in to [Authlete Console](https://console.authlete.com)\n2. Navigate to your service → **Settings** → **Access Tokens**\n3. Click **Create Token** and select permissions (e.g., `service.read`, `client.write`)\n4. Copy the generated token\n\n**Organization Token** - Scoped to your entire organization\n\n1. Log in to [Authlete Console](https://console.authlete.com)\n2. Navigate to **Organization Settings** → **Access Tokens**\n3. Click **Create Token** and select org-level permissions\n4. Copy the generated token\n\n> ⚠️ **Important Note**: Tokens inherit the permissions of the account that creates them. Service tokens can only \n> access their specific service, while organization tokens can access all services within your org.\n\n### Token Security Best Practices\n\n- **Never commit tokens to version control** - Store in environment variables or secure secret managers\n- **Rotate regularly** - Generate new tokens periodically and revoke old ones\n- **Scope appropriately** - Request only the permissions your application needs\n- **Revoke unused tokens** - Delete tokens you're no longer using from the console\n\n### Quick Test\n\nVerify your token works with a simple API call:\n\n```bash\ncurl -X GET https://us.authlete.com/api/service/get/list \\\n -H \"Authorization: Bearer YOUR_ACCESS_TOKEN\"\n```\n\n## \U0001F393 Tutorials\n\nIf you're new to Authlete or want to see sample implementations, these resources will help you get started:\n\n- [Getting Started with Authlete](https://www.authlete.com/developers/getting_started/)\n- [From Sign-Up to the First API Request](https://www.authlete.com/developers/tutorial/signup/)\n\n## \U0001F6E0 Contact Us\n\nIf you have any questions or need assistance, our team is here to help:\n\n- [Contact Page](https://www.authlete.com/contact/)\n"
version: 3.0.16
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
servers:
- description: 🇺🇸 US Cluster
url: https://us.authlete.com
- description: 🇯🇵 Japan Cluster
url: https://jp.authlete.com
- description: 🇪🇺 Europe Cluster
url: https://eu.authlete.com
- description: 🇧🇷 Brazil Cluster
url: https://br.authlete.com
security:
- bearer: []
tags:
- name: CIBA
description: API endpoints for implementing Client-Initiated Backchannel Authentication (CIBA).
x-tag-expanded: false
paths:
/api/{serviceId}/backchannel/authentication:
post:
summary: Process Backchannel Authentication Request
description: 'This API parses request parameters of a [backchannel authentication request](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_request)
and returns necessary data for the authorization server implementation to process the backchannel
authentication request further.
'
x-mint:
metadata:
description: This API parses request parameters of a [backchannel authentication request](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_request) and returns necessary data for the authorization server implementation to process the backchannel authentication request further.
content: "<Accordion title=\"Full description\" defaultOpen={false}>\nThis API is supposed to be called from within the implementation of the [backchannel authentication\nendpoint](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_backchannel_endpoint)\nof the service. The endpoint implementation must extract the request parameters from the\nbackchannel authentication request from the client application and pass them as the value of parameters\nrequest parameter for Authlete's `/backchannel/authentication` API.\nThe value of parameters is the entire entity body (which is formatted in `application/x-www-form-urlencoded`)\nof the request from the client application.\nThe following code snippet is an example in JAX-RS showing how to extract request parameters from\nthe backchannel authentication request.\n```java\n@POST\n@Consumes(MediaType.APPLICATION_FORM_URLENCODED)\npublic Response post(String parameters)\n{\n// 'parameters' is the entity body of the backchannel authentication request.\n......\n}\n```\nThe endpoint implementation does not have to parse the request parameters from the client application\nbecause Authlete's `/backchannel/authentication` API does it.\nThe response from `/backchannel/authentication` API has various parameters. Among them, it is `action`\nparameter that the authorization server implementation should check first because it denotes the\nnext action that the authorization server implementation should take. According to the value of\n`action`, the service implementation must take the steps described below.\n\n## INTERNAL_SERVER_ERROR\n\nWhen the value of `action` is `INTERNAL_SERVER_ERROR`, it means that the request from the authorization\nserver implementation was wrong or that an error occurred in Authlete.\nIn either case, from the viewpoint of the client application, it is an error on the server side.\nTherefore, the service implementation should generate a response to the client application with\nHTTP status of \"500 Internal Server Error\" and `application/json`.\nThe value of `responseContent` is a JSON string which describes the error, so it can be used\nas the entity body of the response.\n\n---\n\nThe following illustrates the response which the service implementation should generate and return\nto the client application.\n```\nHTTP/1.1 500 Internal Server Error\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{responseContent}\n```\n\n## BAD_REQUEST\n\nWhen the value of `action` is `BAD_REQUEST`, it means that the request from the client application\nis invalid.\nThe authorization server implementation should generate a response to the client application with\n\"400 Bad Request\" and `application/json`.\nThe value of `responseContent` is a JSON string which describes the error, so it can be used as\nthe entity body of the response.\n\n---\n\nThe following illustrates the response which the service implementation should generate and return\nto the client application.\n```\nHTTP/1.1 400 Bad Request\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{responseContent}\n```\n\n## UNAUTHORIZED\n\nWhen the value of `action` is `UNAUTHORIZED`, it means that client authentication of the backchannel\nauthentication request failed. Note that client authentication is always required at the backchannel\nauthentication endpoint. This implies that public clients are not allowed to use the backchannel\nauthentication endpoint.\nThe authorization server implementation should generate a response to the client application with\n\"401 Unauthorized\" and `application/json`.\nThe value of `responseContent` is a JSON string which describes the error, so it can be used as\nthe entity body of the response.\n\n---\n\nThe following illustrates the response which the service implementation must generate and return\nto the client application.\n```\nHTTP/1.1 401 Unauthorized\nWWW-Authenticate: (challenge)\nContent-Type: application/json\nCache-Control: no-store\nPragma: no-cache\n{responseContent}\n```\n\n## USER_IDENTIFICATION\n\nWhen the value of `action` is `USER_IDENTIFICATION`, it means that the backchannel authentication\nrequest from the client application is valid. The authorization server implementation has to follow\nthe steps below.\n\n**[1] END-USER IDENTIFICATION**\n\nThe first step is to determine the subject (= unique identifier) of the end-user from whom the\n client application wants to get authorization.\n According to the CIBA specification, a backchannel authentication request contains one (and only\n one) of the `login_hint_token`, `id_token_hint` and `login_hint` request parameters as a hint\n by which the authorization server identifies the subject of an end-user.\n The authorization server implementation can know which hint is included in the backchannel authentication\n request by the `hintType` parameter. For example, when the value of the parameter `LOGIN_HINT`,\n it means that the backchannel authentication request contains the `login_hint` request parameter\n as a hint.\n The value of the `hint` parameter is the value of the hint. For example, when the value of the\n `hintType` parameter is `LOGIN_HINT`, The value of the `hint` parameter is the value of the `login_hint`\n request parameter.\n It is up to the authorization server implementation how to determine the subject of the end-user\n from the hint. Only when the `id_token_hint` request parameter is used, authorization server\n implementation can use the sub response parameter, which holds the value of the sub claim in the\n `id_token_hint` request parameter.\n\n**[2] END-USER IDENTIFICATION ERROR**\n\nThere are some cases where the authorization server implementation encounters an error during\n the user identification process. In any error case, the service implementation has to return an\n HTTP response with the error response parameter to the client application. The following is an\n example of such error responses.\n ```\n HTTP/1.1 400 Bad Request\n Content-Type: application/json\n Cache-Control: no-store\n Pragma: no-cache\n { \"error\":\"unknown_user_id\" }\n ```\n Authlete provides `/backchannel/authentication/fail` API that builds the response body (JSON)\n of an error response. However, because it is easy to build an error response manually, you may\n choose not to call the API. One good thing in using the API is that the API call can trigger\n deletion of the ticket which has been issued from Authlete's `/backchannel/authentication` API.\n If you don't call `/backchannel/authentication/fail` API, the ticket will continue to exist in\n the database until it is cleaned up by the batch program after the ticket expires.\n Possible error cases that the authorization server implementation itself has to handle are as\n follows. Other error cases have already been covered by `/backchannel/authentication` API.\n- `expired_login_hint_token`\nThe authorization server implementation detected that the hint presented by the `login_hint_token`\nrequest parameter has expired.\nNote that the format of `login_hint_token` is not described in the CIBA Core spec at all and\nso there is no consensus on how to detect expiration of `login_hint_token`. Interpretation\nof `login_hint_token` is left to each authorization server implementation.\n- `unknown_user_id`\nThe authorization server implementation could not determine the subject of the end-user by\nthe presented hint.\n- `unauthorized_client`\nThe authorization server implementation has custom rules to reject backchannel authentication\nrequests from some particular clients and found that the client which has made the backchannel\nauthentication request is one of the particular clients.\nNote that `/backchannel/authentication` API does not return `action=USER_IDENTIFICATION` in\ncases where the client does not exist or client authentication has failed. Therefore, the\nauthorization server implementation will never have to use the error code `unauthorized_client`\nunless the server has intentionally implemented custom rules to reject backchannel authentication\nrequests based on clients.\n- `missing_user_code`\nThe authorization server implementation has custom rules to require that a backchannel authentication\nrequest include a user code for some particular users and found that the user identified by\nthe hint is one of the particular users.\nNote that `/backchannel/authentication` API does not return `action=USER_IDENTIFICATION` when\nboth the `backchannel_user_code_parameter_supported` metadata of the server and the\n`backchannel_user_code_parameter` metadata of the client are true and the backchannel authentication\nrequest does not include the user_code request parameter. In this case, `/backchannel/authentication`\nAPI returns action=BAD_REQUEST with JSON containing `\"error\":\"missing_user_code\"`. Therefore,\nthe authorization server implementation will never have to use the error code `missing_user_code`\nunless the server has intentionally implemented custom rules to require a user code based\non users even in the case where the `backchannel_user_code_parameter` metadata of the client\nwhich has made the backchannel authentication request is `false`.\n- `invalid_user_code`\nThe authorization server implementation detected that the presented user code is invalid.\nNote that the format of user_code is not described in the CIBA Core spec at all and so there\nis no consensus on how to judge whether a user code is valid or not. It is up to each authorization\nserver implementation how to handle user codes.\n- `invalid_binding_message`\nThe authorization server implementation detected that the presented binding message is invalid.\nNote that the format of binding_message is not described in the CIBA Core spec at all and\nso there is no consensus on how to judge whether a binding message is valid or not. It is\nup to each authorization server implementation how to handle binding messages.\n- `invalid_target`\nThe authorization server implementation rejects the requested target resources.\nThe error code invalid_target is from \"Resource Indicators for OAuth 2.0\". The specification\ndefines the resource request parameter. By using the parameter, client applications can request\ntarget resources that should be bound to the access token being issued. If the authorization\nserver wants to reject the request, call `/backchannel/authentication/fail` API with `INVALID_TARGET`.\n- `access_denined`\nThe authorization server implementation has custom rules to reject backchannel authentication\nrequests without asking the end-user and respond to the client as if the end-user had rejected\nthe request in some particular cases and found that the backchannel authentication request\nis one of the particular cases.\nThe authorization server implementation will never have to use the error code `access_denied`\nat this timing unless the server has intentionally implemented custom rules to reject backchannel\nauthentication requests without asking the end-user and respond to the client as if the end-user\nhad rejected the request.\n\n**[3] AUTH_REQ_ID ISSUE**\n\nIf the authorization server implementation has successfully determined the subject of the end-user,\n the next action is to return an HTTP response to the client application which contains `auth_req_id`.\n Authlete provides `/backchannel/authentication/issue` API which generates a JSON containing `auth_req_id`,\n so, your next action is (1) call the API, (2) receive the response from the API, (3) build a response\n to the client application using the content of the API response, and (4) return the response to\n the client application. See the description of `/backchannel/authentication/issue` API for details.\n\n**[4] END-USER AUTHENTICATION AND AUTHORIZATION**\n\nAfter sending a JSON containing `auth_req_id` back to the client application, the service implementation\n starts to communicate with an authentication device of the end-user. It is assumed that end-user\n authentication is performed on the authentication device and the end-user confirms the content of\n the backchannel authentication request and grants authorization to the client application if everything\n is okay. The authorization server implementation must be able to receive the result of the end-user\n authentication and authorization from the authentication device.\n How to communicate with an authentication device and achieve end-user authentication and authorization\n is up to each authorization server implementation, but the following request parameters of the backchannel\n authentication request should be taken into consideration in any implementation.\n- `acr_values`\nA backchannel authentication request may contain an array of ACRs (Authentication Context Class\nReferences) in preference order. If multiple authentication devices are registered for the end-user,\nthe authorization server implementation should take the ACRs into consideration when selecting\nthe best authentication device.\n- `scope`\nA backchannel authentication request always contains a list of scopes. At least, `openid` is\nincluded in the list (otherwise `/backchannel/authentication` API returns `action=BAD_REQUEST`).\nIt would be better to show the requested scopes to the end-user on the authentication device\nor somewhere appropriate.\nIf the scope request parameter contains `address`, `email`, `phone` and/or `profile`, they are\ninterpreted as defined in \"5.4. Requesting Claims using Scope Values of OpenID Connect Core 1.0\".\nThat is, they are expanded into a list of claim names. The claimNames parameter returns the expanded\nresult.\n- `binding_message`\nA backchannel authentication request may contain a binding message. It is a human readable identifier\nor message intended to be displayed on both the consumption device (client application) and the\nauthentication device.\n- `user_code`\nA backchannel authentication request may contain a user code. It is a secret code, such as password\nor pin, known only to the end-user but verifiable by the authorization server. The user code should\nbe used to authorize sending a request to the authentication device.\n\n**[5] END-USER AUTHENTICATION AND AUTHORIZATION COMPLETION**\n\nAfter receiving the result of end-user authentication and authorization, the authorization server\n implementation must call Authlete's `/backchannel/authentication/complete` API to tell Authlete\n the result and pass necessary data so that Authlete can generate an ID token, an access token and\n optionally a refresh token. See the description of the API for details.\n\n**[6] CLIENT NOTIFICATION**\n\nWhen the backchannel token delivery mode is either `ping` or `push`, the authorization server implementation\n must send a notification to the pre-registered notification endpoint of the client after the end-user\n authentication and authorization. In this case, the `action` parameter in a response from `/backchannel/authentication/complete`\n API is `NOTIFICATION`. See the description of `/backchannel/authentication/complete` API for details.\n\n**[7] TOKEN REQUEST**\n\nWhen the backchannel token delivery mode is either `ping` or `poll`, the client application will make\n a token request to the token endpoint to get an ID token, an access token and optionally a refresh\n token.\n A token request that corresponds to a backchannel authentication request uses `urn:openid:params:grant-type:ciba`\n as the value of the `grant_type` request parameter. Authlete's `/auth/token` API recognizes the\n grant type automatically and behaves properly, so the existing token endpoint implementation does\n not have to be changed to support CIBA.\n</Accordion>\n"
parameters:
- in: path
name: serviceId
description: A service ID.
required: true
schema:
type: string
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/backchannel_authentication_request'
example:
parameters: login_hint=john&scope=openid&client_notification_token=my-client-notification-token&user_code=my-user-code
clientId: '26862190133482'
clientSecret: 8J9pAEX6IQw7lYtYGsc_s9N4jlEz_DfkoCHIswJjFjfgKZX-nC4EvKtaHXcP9mHBfS7IU4jytjSZZpaK9UJ77A
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/backchannel_authentication_request'
responses:
'200':
description: ''
content:
application/json:
schema:
$ref: '#/components/schemas/backchannel_authentication_response'
example:
resultCode: A179001
resultMessage: '[A179001] The backchannel authentication request was processed successfully.'
action: USER_IDENTIFICATION
clientId: 26862190133482
clientIdAliasUsed: false
clientName: My CIBA Client
clientNotificationToken: my-client-notification-token
deliveryMode: POLL
hint: john
hintType: LOGIN_HINT
requestedExpiry: 0
scopes:
- defaultEntry: false
name: openid
serviceAttributes:
- key: attribute1-key
value: attribute1-value
- key: attribute2-key
value: attribute2-value
ticket: Y1qeCf0A-JUz6caceaBfd2AaBYNZ-X-WGTP5Qv47cQI
userCode: my-user-code
userCodeRequired: false
'400':
$ref: '#/components/responses/400'
'401':
$ref: '#/components/responses/401'
'403':
$ref: '#/components/responses/403'
'500':
$ref: '#/components/responses/500'
operationId: backchannel_authentication_api
x-code-samples:
- lang: shell
label: curl
source: 'curl -v -X POST https://us.authlete.com/api/21653835348762/backchannel/authentication \
-H ''Content-Type: application/json'' \
-H ''Authorization: Bearer V5a40R6dWvw2gMkCOBFdZcM95q4HC0Z-T0YKD9-nR6F'' \
-d ''{ "parameters": "login_hint=john&scope=openid&client_notification_token=my-client-notification-token&user_code=my-user-code", "clientId": "26862190133482", "clientSecret":"8J9pAEX6IQw7lYtYGsc_s9N4jlEz_DfkoCHIswJjFjfgKZX-nC4EvKtaHXcP9mHBfS7IU4jytjSZZpaK9UJ77A" }''
'
- lang: java
label: java
source: 'AuthleteConfiguration conf = ...;
AuthleteApi api = AuthleteApiFactory.create(conf);
BackchannelAuthenticationRequest req = new BackchannelAuthenticationRequest();
req.setParameters(...);
req.setClientId("26862190133482");
req.setClientSecret("8J9pAEX6IQw7lYtYGsc_s9N4jlEz_DfkoCHIswJjFjfgKZX-nC4EvKtaHXcP9mHBfS7IU4jytjSZZpaK9UJ77A");
api.backchannelAuthentication(req);
'
- lang: python
source: 'conf = ...
api = AuthleteApiImpl(conf)
req = BackchannelAuthenticationRequest()
req.parameters = ...
req.clientId = ''26862190133482''
req.clientSecret = ''8J9pAEX6IQw7lYtYGsc_s9N4jlEz_DfkoCHIswJjFjfgKZX-nC4EvKtaHXcP9mHBfS7IU4jytjSZZpaK9UJ77A''
api.backchannelAuthentication(req)
'
tags:
- CIBA
/api/{serviceId}/backchannel/authentication/issue:
post:
summary: Issue Backchannel Authentication Response
description: 'This API prepares JSON that contains an `auth_req_id`. The JSON should be used as the response body
of the response which is returned to the client from the [backchannel authentication endpoint](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_backchannel_endpoint)
'
x-mint:
metadata:
description: This API prepares JSON that contains an `auth_req_id`. The JSON should be used as the response body of the response which is returned to the client from the [backchannel authentication endpoint](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_backchannel_endpoint)
content: '<Accordion title="Full description" defaultOpen={false}>
This API is supposed to be called from within the implementation of the backchannel authentication
endpoint of the service in order to generate a successful response to the client application.
The description of the `/backchannel/authentication` API describes the timing when this API should
be called and the meaning of request parameters. See [AUTH_REQ_ID ISSUE] in `USER_IDENTIFICATION`.
The response from `/backchannel/authentication/issue` API has some parameters. Among them, it is
`action` parameter that the authorization server implementation should check first because it denotes
the next `action` that the authorization server implementation should take. According to the value
of `action`, the authorization server implementation must take the steps described below.
```java
@POST
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response post(String parameters)
{
// ''parameters'' is the entity body of the backchannel authentication request.
......
}
```
The endpoint implementation does not have to parse the request parameters from the client application
because Authlete''s `/backchannel/authentication` API does it.
The response from `/backchannel/authentication` API has various parameters. Among them, it is `action`
parameter that the authorization server implementation should check first because it denotes the
next action that the authorization server implementation should take. According to the value of
`action`, the service implementation must take the steps described below.
## INTERNAL_SERVER_ERROR
When the value of `action` is `INTERNAL_SERVER_ERROR`, it means that the request from the authorization
server implementation was wrong or that an error occurred in Authlete.
In either case, from the viewpoint of the client application, it is an error on the server side.
Therefore, the service implementation should generate a response to the client application with
HTTP status of "500 Internal Server Error" and `application/json`.
The value of `responseContent` is a JSON string which describes the error, so it can be used as
the entity body of the response.
---
The following illustrates the response which the service implementation should generate and return
to the client application.
```
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{responseContent}
```
## INVALID_TICKET
When the value of `action` is `INVALID_TICKET`, it means that the ticket included in the API call
was invalid. For example, it does not exist or has expired.
From a viewpoint of the client application, this is an error on the server side. Therefore, the
authorization server implementation should generate a response to the client application with
"500 Internal Server Error" and `application/json`.
You can build an error response in the same way as shown in the description for the case of `INTERNAL_SERVER_ERROR`.
## OK
When the value of `action` is `OK`, it means that Authlete has succeeded in preparing JSON that
contains an `auth_req_id`. The JSON should be used as the response body of the response that is
returned to the client from the backchannel authentication endpoint. `responseContent` contains
the JSON.
The following illustrates the response which the authorization server implementation should generate
and return to the client application.
```
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{responseContent}
```
</Accordion>
'
parameters:
- in: path
name: serviceId
description: A service ID.
required: true
schema:
type: string
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/backchannel_authentication_issue_request'
example:
ticket: NFIHGx_btVrWmtAD093D-87JxvT4DAtuijEkLVHbS4Q
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/backchannel_authentication_issue_request'
responses:
'200':
description: Backchannel authentication issued successfully
content:
application/json:
schema:
$ref: '#/components/schemas/backchannel_authentication_issue_response'
example:
resultCode: A183001
resultMessage: '[A183001] An auth_req_id was issued successfully.'
action: OK
authReqId: _mzc-ZQdAhSPuMxTlO-MC_oqaOqYCrdNQ39PVxisaiE
expiresIn: 3600
interval: 0
responseContent: '{\"auth_req_id\":\"_mzc-ZQdAhSPuMxTlO-MC_oqaOqYCrdNQ39PVxisaiE\",\"interval\":0,\"expires_in\":3600}'
'400':
$ref: '#/components/responses/400'
'401':
$ref: '#/components/responses/401'
'403':
$ref: '#/components/responses/403'
'500':
$ref: '#/components/responses/500'
operationId: backchannel_authentication_issue_api
x-code-samples:
- lang: shell
label: curl
source: 'curl -v -X POST https://us.authlete.com/api/21653835348762/backchannel/authentication/issue \
-H ''Content-Type: application/json'' \
-H ''Authorization: Bearer V5a40R6dWvw2gMkCOBFdZcM95q4HC0Z-T0YKD9-nR6F'' \
-d ''{ "ticket": "NFIHGx_btVrWmtAD093D-87JxvT4DAtuijEkLVHbS4Q" }''
'
- lang: java
label: java
source: 'AuthleteConfiguration conf = ...;
AuthleteApi api = AuthleteApiFactory.create(conf);
BackchannelAuthenticationIssueRequest req = new BackchannelAuthenticationIssueRequest();
req.setTicket("NFIHGx_btVrWmtAD093D-87JxvT4DAtuijEkLVHbS4Q");
api.backchannelAuthenticationIssue(req);
'
- lang: python
source: 'conf = ...
api = AuthleteApiImpl(conf)
req = BackchannelAuthenticationIssueRequest()
req.ticket = ''NFIHGx_btVrWmtAD093D-87JxvT4DAtuijEkLVHbS4Q''
api.backchannelAuthenticationIssue(req)
'
tags:
- CIBA
/api/{serviceId}/backchannel/authentication/fail:
post:
summary: Fail Backchannel Authentication Request
description: 'The API prepares JSON that contains an error. The JSON should be used as the response body of the
response which is returned to the client from the [backchannel authentication endpoint](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#auth_backchannel_endpoint).
'
x-mi
# --- truncated at 32 KB (87 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/authlete/refs/heads/main/openapi/authlete-ciba-api-openapi.yml