...
getDevices - list keys associated with a user
deleteDevices - delete a key associated with a key ID
Motivation
If an attacker obtained a users Refresh Token, the person could exchange the token for an Access Token (AT) from the Authorization Server, and maliciously act as the user. Therefore the Refresh Token (RT) needs to be stored securely on a users device. A naive approach is to encrypt the Refresh Token with a user chosen password. This password is usually vulnerable to brute force attacks. Therefore, we encrypt the Refresh Token with a 128 bit key, which the user can access from a web service, in such a way, that the service locks the key, if numerous invalid attempts are made at accessing the key. Thus leaving brute force attacks on getting access to the key infeasible.
...
When the Keyservice generates a new Key, the service also generates a 128 bit long secret. This long secret can also be used to retrieve the users Key from Keyservice, in the same way as the user chosen password. By storing the long secret in the biometrically secured safe storage on a device, if an attacker managed to access the safe storage, the potentially long list of other applications secured by the users password would not be compromised.
Usage
The following diagram illustrates how an app obtains a valid set of tokens and client credentials from an Authorization Server (Keycloak), creates a key on the Keyservice for encrypting and securely storing the client credentials and RT on a users device, and successfully uses the AT for interacting with the FUT infrastructure.
...
Or by authenticating using bio-metrics on a mobile device, and decrypt the Client Credentials and Refresh Token using the long secret:
...
...
Keyservice management
There are 2 types of management,
...