Authentication approval

Search…
​
If the user approves the authentication request, the PKSA must:
create a new token with an expire value or reuse an existing one.
store the token, expire and key values locally.
create an "authentication approval data" object (auth_ack_data) that it will send to the APP
The structure of the auth_ack_data is:
auth_ack_data
1
{
2
    token: string,
3
    expire: number,
4
    challenge: object = undefined
5
}
Copied!
Properties
token: session token (we recommend using a UUID)
expire: UNIX timestamp when the token will expire
challenge: optional if the APP provided a challenge_data object with its auth_req_data, the PKSA must return a challenge_ack_data object (see Challenge approval ).
The PKSA must then encrypt the auth_ack_data object using the encryption key previously shared with the APP (auth_key).
Finally, the PKSA then inform the HAS of the user's approval by sending the following message:
auth_ack
1
{
2
    cmd: "auth_ack",
3
    uuid: string,
4
    data: string
5
}
Copied!
Properties
uuid: the request identifier
data: auth_ack_data encrypted with the auth_key and converted to Base64
The encryption of auth_ack_data is performed to ensure that a malicious actor operating a HAS cannot bypass the PKSA to approve an authentication request.
It will also make the HAS unaware of what's going on between the app and the PKSA and unable to tamper with the authentication request process.
Being the only one being able to decrypt the auth_ack.challenge using its encryption key, the APP has 100% certainty that the encryption process was made by a PKSA which got the encryption key from reading the off-band auth_req_payload.
Feedback to user
Authentication refusal
Last modified 5mo ago
Copy link
Contents
auth_ack_data
auth_ack