Authentication approval
If the user approves the authentication request, the PKSA must:
- create a new
token
with anexpire
value or reuse an existing one. - store the
token
,expire
andkey
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:{
token: string, // protocol < 1.0 only
expire: number,
challenge: object = undefined
}
Properties
token
: session token (we recommend using a UUID) - Deprecated since protocol v1.0expire
: UNIX timestamp when the authentication will expirechallenge
: optional if the APP provided achallenge_data
object with itsauth_req_data
, the PKSA must return achallenge_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:
{
cmd: "auth_ack",
uuid: string,
data: string,
pok: string
}
Properties
uuid
: the request identifierdata
:auth_ack_data
encrypted with theauth_key
and converted to Base64pok
: theuuid
encrypted using the account private key and the HAS server public key (see Proof of Key)
The encryption ofauth_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 theauth_ack.challenge
using its encryptionauth_key
, the APP has 100% certainty that the encryption process was made by a PKSA which got the encryptionauth_key
from reading the off-bandauth_req_payload
.
Last modified 6d ago