Skip to main content
POST
/
api
/
{serviceId}
/
backchannel
/
authentication
/
issue
Typescript (SDK)
import { Authlete } from "@authlete/typescript-sdk";

const authlete = new Authlete({
  bearer: process.env["AUTHLETE_BEARER"] ?? "",
});

async function run() {
  const result = await authlete.ciba.issue({
    serviceId: "<id>",
    backchannelAuthenticationIssueRequest: {
      ticket: "NFIHGx_btVrWmtAD093D-87JxvT4DAtuijEkLVHbS4Q",
    },
  });

  console.log(result);
}

run();
{
  "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}"
}
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.
@POST
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response post(String parameters)
&#123;
// 'parameters' is the entity body of the backchannel authentication request.
......
&#125;
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
&#123;responseContent&#125;

​
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
&#123;responseContent&#125;

Authorizations

​
Authorization
string
header
required

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

​
serviceId
string
required

A service ID.

Body

​
ticket
string
required

The ticket issued from Authlete's /backchannel/authentication API.

Response

Backchannel authentication issued successfully

​
resultCode
string

The code which represents the result of the API call.

​
resultMessage
string

A short message which explains the result of the API call.

​
action
enum<string>

The next action that the authorization server implementation should take.

Available options:
INTERNAL_SERVER_ERROR,
INVALID_TICKET,
OK
​
responseContent
string

The content that the authorization server implementation is to return to the client application. Its format varies depending on the value of action parameter.

​
authReqId
string

The newly issued authentication request ID.

​
expiresIn
integer<int32>

The duration of the issued authentication request ID in seconds.

​
interval
integer<int32>

The minimum amount of time in seconds that the client must wait for between polling requests to the token endpoint.