Process Backchannel Authentication Request

@POST
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response post(String parameters)
{
// 'parameters' is the entity body of the backchannel authentication request.
......
}

​

INTERNAL_SERVER_ERROR

HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{responseContent}

​

BAD_REQUEST

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{responseContent}

​

UNAUTHORIZED

HTTP/1.1 401 Unauthorized
WWW-Authenticate: (challenge)
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{responseContent}

​

USER_IDENTIFICATION

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{ "error":"unknown_user_id" }

• expired_login_hint_token The authorization server implementation detected that the hint presented by the login_hint_token request parameter has expired. Note that the format of login_hint_token is not described in the CIBA Core spec at all and so there is no consensus on how to detect expiration of login_hint_token. Interpretation of login_hint_token is left to each authorization server implementation.
• unknown_user_id The authorization server implementation could not determine the subject of the end-user by the presented hint.
• unauthorized_client The authorization server implementation has custom rules to reject backchannel authentication requests from some particular clients and found that the client which has made the backchannel authentication request is one of the particular clients. Note that /backchannel/authentication API does not return action=USER_IDENTIFICATION in cases where the client does not exist or client authentication has failed. Therefore, the authorization server implementation will never have to use the error code unauthorized_client unless the server has intentionally implemented custom rules to reject backchannel authentication requests based on clients.
• missing_user_code The authorization server implementation has custom rules to require that a backchannel authentication request include a user code for some particular users and found that the user identified by the hint is one of the particular users. Note that /backchannel/authentication API does not return action=USER_IDENTIFICATION when both the backchannel_user_code_parameter_supported metadata of the server and the backchannel_user_code_parameter metadata of the client are true and the backchannel authentication request does not include the user_code request parameter. In this case, /backchannel/authentication API returns action=BAD_REQUEST with JSON containing "error":"missing_user_code". Therefore, the authorization server implementation will never have to use the error code missing_user_code unless the server has intentionally implemented custom rules to require a user code based on users even in the case where the backchannel_user_code_parameter metadata of the client which has made the backchannel authentication request is false.
• invalid_user_code The authorization server implementation detected that the presented user code is invalid. Note that the format of user_code is not described in the CIBA Core spec at all and so there is no consensus on how to judge whether a user code is valid or not. It is up to each authorization server implementation how to handle user codes.
• invalid_binding_message The authorization server implementation detected that the presented binding message is invalid. Note that the format of binding_message is not described in the CIBA Core spec at all and so there is no consensus on how to judge whether a binding message is valid or not. It is up to each authorization server implementation how to handle binding messages.
• invalid_target The authorization server implementation rejects the requested target resources. The error code invalid_target is from “Resource Indicators for OAuth 2.0”. The specification defines the resource request parameter. By using the parameter, client applications can request target resources that should be bound to the access token being issued. If the authorization server wants to reject the request, call /backchannel/authentication/fail API with INVALID_TARGET.
• access_denined The authorization server implementation has custom rules to reject backchannel authentication requests without asking the end-user and respond to the client as if the end-user had rejected the request in some particular cases and found that the backchannel authentication request is one of the particular cases. The authorization server implementation will never have to use the error code access_denied at this timing unless the server has intentionally implemented custom rules to reject backchannel authentication requests without asking the end-user and respond to the client as if the end-user had rejected the request.

• acr_values A backchannel authentication request may contain an array of ACRs (Authentication Context Class References) in preference order. If multiple authentication devices are registered for the end-user, the authorization server implementation should take the ACRs into consideration when selecting the best authentication device.
• scope A backchannel authentication request always contains a list of scopes. At least, openid is included in the list (otherwise /backchannel/authentication API returns action=BAD_REQUEST). It would be better to show the requested scopes to the end-user on the authentication device or somewhere appropriate. If the scope request parameter contains address, email, phone and/or profile, they are interpreted as defined in “5.4. Requesting Claims using Scope Values of OpenID Connect Core 1.0”. That is, they are expanded into a list of claim names. The claimNames parameter returns the expanded result.
• binding_message A backchannel authentication request may contain a binding message. It is a human readable identifier or message intended to be displayed on both the consumption device (client application) and the authentication device.
• user_code A backchannel authentication request may contain a user code. It is a secret code, such as password or pin, known only to the end-user but verifiable by the authorization server. The user code should be used to authorize sending a request to the authentication device.