This API returns information about what action the authorization server should take after it receives the result of end-user’s decision about whether the end-user has approved or rejected a client application’s request on the authentication device.
Full description
auth_req_id to the client, the authorization server starts a background process that communicates
with the authentication device of the end-user. On the authentication device, end-user authentication
is performed and the end-user is asked whether they give authorization to the client or not. The
authorization server will receive the result of end-user authentication and authorization from
the authentication device.
After the authorization server receives the result from the authentication device, or even in the
case where the server gave up receiving a response from the authentication device for some reasons,
the server should call the /backchannel/authentication/complete API to tell Authlete the result.
When the end-user was authenticated and authorization was granted to the client by the end-user,
the authorization server should call the API with result=AUTHORIZED. In this successful case,
the subject request parameter is mandatory. If the token delivery mode is push, the API will generate
an access token, an ID token and optionally a refresh token. On the other hand, if the token delivery
mode is poll or ping, the API will just update the database record so that /auth/token API
can generate tokens later.
When the authorization server received the decision of the end-user from the authentication device
and it indicates that the end-user has rejected to give authorization to the client, the authorization
server should call the API with result=ACCESS_DENIED. In this case, if the token delivery mode
is push, the API will generate an error response that contains the error response parameter and
optionally the error_description and error_uri response parameters (if the errorDescription
and errorUri request parameters have been given). On the other hand, if the token delivery mode
is poll or ping, the API will just update the database record so that /auth/token API can
generate an error response later. In any token delivery mode, the value of the error parameter will
become access_denied.
When the authorization server could not get the result of end-user authentication and authorization
from the authentication device for some reasons, the authorization server should call the API with
result=TRANSACTION_FAILED. In this error case, the API will behave in the same way as in the case
of ACCESS_DENIED. The only difference is that expired_token is used as the value of the error
parameter.
The response from /backchannel/authentication/complete 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.action is SERVER_ERROR, it means either (1) that the request from the authorization
server to Authlete was wrong, or (2) that an error occurred on Authlete side.
When the backchannel token delivery mode is ping or push, SERVER_ERROR is used only when
an error is detected before the record of the ticket (which is included in the API call to /backchannel/authentication/complete)
is retrieved from the database successfully. If an error is detected after the record of the ticket
is retrieved from the database, NOTIFICATION is used instead of SERVER_ERROR.
When the backchannel token delivery mode is poll, SERVER_ERROR is used regardless of whether
it is before or after the record of the ticket is retrieved from the database.action is NO_ACTION, it means that the authorization server does not have
to take any immediate action.
NO_ACTION is returned when the backchannel token delivery mode is poll. In this case, the client
will receive the final result at the token endpoint.action is NOTIFICATION, it means that the authorization server must send a
notification to the client notification endpoint.
According to the CIBA Core specification, the notification is an HTTP POST request whose request
body is JSON and whose Authorization header contains the client notification token, which was
included in the backchannel authentication request as the value of the client_notification_token
request parameter, as a bearer token.
When the backchannel token delivery mode is ping, the request body of the notification is JSON
which contains the auth_req_id property only. When the backchannel token delivery mode is push,
the request body will additionally contain an access token, an ID token and other properties. Note
that when the backchannel token delivery mode is poll, a notification does not have to be sent
to the client notification endpoint.
In error cases, in the ping mode, however, the content of a notification is not different from the
content in successful cases. That is, the notification contains the auth_req_id property only.
The client will know the error when it accesses the token endpoint. On the other hand, in the
push mode, in error cases, the content of a notification will include the error property instead
of an access token and an ID token. The client will know the error by detecting that error is included
in the notification.
In any case, the value of responseContent is JSON which can be used as the request body of the
notification.
The client notification endpoint that the notification should be sent to the value of the clientNotificationEndpoint
parameter. Likewise, the client notification token that the notification should include as a bearer
token is the clientNotificationToken parameter. With these methods, the notification can be built
like the following.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.
A service ID.
The ticket issued by Authlete's /backchannel/authentication API.
The result of the end-user authentication and authorization. One of the following. Details are described in the description.
TRANSACTION_FAILED, ACCESS_DENIED, AUTHORIZED The subject (= unique identifier) of the end-user.
The value of the sub claim that should be used in the ID token.
The time at which the end-user was authenticated. Its value is the number of seconds from 1970-01-01.
The reference of the authentication context class which the end-user authentication satisfied.
Additional claims which will be embedded in the ID token.
The extra properties associated with the access token.
Scopes to replace the scopes specified in the original backchannel authentication request with. When nothing is specified for this parameter, replacement is not performed.
JSON that represents additional JWS header parameters for ID tokens.
The description of the error. If this optional request parameter is given, its value is used as
the value of the error_description property, but it is used only when the result is not AUTHORIZED.
To comply with the specification strictly, the description must not include characters outside
the set %x20-21 / %x23-5B / %x5D-7E.
The URI of a document which describes the error in detail. This corresponds to the error_uri
property in the response to the client.
the claims that the user has consented for the client application to know.
Additional claims that are added to the payload part of the JWT access token.
The representation of an access token that may be issued as a result of the Authlete API call.
The duration (in seconds) of the access token that may be issued as a result of the Authlete API call.
When this request parameter holds a positive integer, it is used as the duration of the access token in. In other cases, this request parameter is ignored.
The duration (in seconds) of the refresh token that may be issued as a result of the Authlete API call.
When this request parameter holds a positive integer, it is used as the duration of the refresh token in. In other cases, this request parameter is ignored.
The type of the aud claim of the ID token being issued. Valid values are as follows.
| Value | Description |
|---|---|
| "array" | The type of the aud claim is always an array of strings. |
| "string" | The type of the aud claim is always a single string. |
| null | The type of the aud claim remains the same as before. |
This request parameter takes precedence over the idTokenAudType property of the service.
Backchannel authentication completed successfully
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.
SERVER_ERROR, NO_ACTION, NOTIFICATION The content that the authorization server implementation is to return to the client
application. Its format varies depending on the value of action parameter.
The client ID of the client application that has made the backchannel authentication request.
The client ID alias of the client application that has made the backchannel authentication request.
true if the value of the client_id request parameter included in the backchannel
authentication request is the client ID alias. false if the value is the original
numeric client ID.
The name of the client application which has made the backchannel authentication request.
PING, POLL, PUSH The client notification endpoint to which a notification needs to be sent. This corresponds
to the client_notification_endpoint metadata of the client application.
The client notification token which needs to be embedded as a Bearer token in the Authorization
header in the notification. This is the value of the client_notification_token request
parameter included in the backchannel authentication request.
The newly issued authentication request ID.
The issued access token.
The issued refresh token.
The issued ID token.
The duration of the access token in seconds.
The duration of the refresh token in seconds.
The duration of the ID token in seconds.
The issued access token in JWT format.
The resources specified by the resource request parameters or by the resource property
in the request object. If both are given, the values in the request object should be
set. See "Resource Indicators for OAuth 2.0" for details.
The authorization details. This represents the value of the authorization_details
request parameter in the preceding device authorization request which is defined in
"OAuth 2.0 Rich Authorization Requests".
The attributes of this service that the client application belongs to.
The attributes of the client.
the value of the grant_id request parameter of the device authorization request.
The grant_id request parameter is defined in
Grant Management for OAuth 2.0
, which is supported by Authlete 2.3 and newer versions.
The entity ID of the client.
Flag which indicates whether the entity ID of the client was used when the request for the access token was made.
The location of the client's metadata document that was used to resolve client metadata.
This property is set when client metadata was retrieved via the OAuth Client ID Metadata Document (CIMD) mechanism.
Flag indicating whether a metadata document was used to resolve client metadata for this request.
When true, the client metadata was retrieved via the CIMD mechanism rather than from the Authlete database.