This has been an age old issue in web access management technologies, both for stateless and stateful token types, OAuth2 access and refresh tokens, as well as OpenID Connect id tokens.
In the hyper connected Consumer Identity & Access Management (CIAM) and Internet (Identity) of Things worlds, this can become a big problem.
Token misuse, perhaps via MITM (man in the middle) attacks, or even resource server misconfiguration, could result in considerable data compromise.
However, there are some newer standards that look to add some binding ability to the tokens - that is, glue them to a particular user or device based on some simple crypto.
The unstable nightly source and build of OpenAM has added the proof of possession capability to the OAuth2 provider service. (Perhaps the first vendor to do so? Email me if you see other implementations..).
The idea is, that the client makes a normal request for an access_token from the authorization service (AS), but also adds another parameter in the request, that contains some crypto the client has access to - basically a public key of an asymmetric key pair.
This key, which could be ephemeral for that request, is then baked into the access_token. If the access_token is a JWT, the JWT contains this public key and the JWT is then signed by the authorization service. If using a stateful access_token, the AS token introspection endpoint can relay the public key back to the resource server at look up time.
This basically gives the RS an option to then issue a challenge response style interaction with the client to see if they are in possession of the private key pair - thus proving they are the correct recipient of the originally issued access_token!
The basic flow, sees the addition of a new parameter to the access_token request to the OpenAM authorization service, under the name of "cnf_key". This is a confirmation key, that the client is in possession of. In this example, it would be a base64 encoded JSON Web Key representation of a public key.
So for example, a POST request to the endpoint ../openam/oauth2/access_token, would now take the parameters grant_type, scope and also cnf_key, with an authorization header containing the OAuth2 client id and secret as normal. A cnf_key could look something like this:
eyJqd2siOnsKICAiYWxnIjogIlJTMjU2IiwKICAiZSI6ICJBUUFCIiwKICAibiI6ICJ2TDM0UXh5bXdId1dEOVpWTDljaU42Yk5ybk91NTI0cjdZMzRvUlJXRkpjWjc3S1dXaHB1Si1iSlZXVVNUd3ZKTGdWTWlDZmFxSTZEWnIwNWQ2VGdONTNfMklVWmtHLXgzNnBFbDZZRWs1d1ZnX1ExelFkeEZHZkRoeFBWajJ3TWNNcjFyR0h1UUFEeC1qV2JHeGRHLTJXMXFsVEdQT253SklqYk9wVm1RYUJjNHhSYndqenNsdG1tcndzMmZNTUtNTDVqbnFwR2RoeWRfdXlFTU0wdHpNTGFNSVN2M2lmeFM2UUw3c2tpZTZ5ajJxamxUTUd3QjA4S29ZUEQ2QlVPaXd6QWxkUmJfM3k4bVA2TXY5cDdvQXBheTZCb25pWU8yaVJySzMxUlRaLVlWUHRleTllSWZ1d0ZFc0RqVzNES0JBS21rMlhGY0NkTHEyU1djVWFOc1EiLAogICJrdHkiOiAiUlNBIiwKICAidXNlIjogInNpZyIsCiAgImtpZCI6ICJzbW9mZi1rZXkiCn19Cg==
Running that through base64 -d on bash, or via an online base64 decoder, shows something like the following: (NB this JWK was created using an online tool for simple testing)
{
"jwk":{
"alg": "RS256",
"e": "AQAB",
"n": "vL34QxymwHwWD9ZVL9ciN6bNrnOu524r7Y34oRRWFJcZ77KWWhpuJ- bJVWUSTwvJLgVMiCfaqI6DZr05d6TgN53_2IUZkG- x36pEl6YEk5wVg_Q1zQdxFGfDhxPVj2wMcMr1rGHuQADx-jWbGxdG-2W1qlTGPOnwJIjbOpVmQaBc4xRbwjzsltmmrws2fMMKML5jnqpGdhyd_uyEMM0tzMLaMISv3ifxS6QL7skie6yj2qjlTMGwB08KoYPD6BUOiwzAldRb_3y8mP6Mv9p7oApay6BoniYO2iRrK31RTZ-YVPtey9eIfuwFEsDjW3DKBAKmk2XFcCdLq2SWcUaNsQ",
"kty": "RSA",
"use": "sig",
"kid": "smoff-key"
}
}
The authorization service, should then return the normal access_token payload. If using stateless OAuth2 access_tokens, the access_token will contain the new embedded cnf_key attribute, containing the originally submitted public key.
The client can then present the access_token back to the RS at access time. The resource server, can then leverage the public key to perform some out of band challenge response questions of the client, when the client comes to present the access_token later.
If using the more traditional stateful access_tokens, the RS can call the ../oauth2/introspect endpoint, sending in the presented access_token as a parameter, to find the public key. An introspected access_token could look like the following, with the newly added cnf_key attribute baked within:
{
"access_token": "7b64b9b3-e4ba-4e0b-b165-a71594f400ed",
"grant_type": "password",
"scope": [
"email"
],
"realm": "/",
"cnf": {
"jwk": {
"alg": "RS256",
"e": "AQAB",
"n": "vL34QxymwHwWD9ZVL9ciN6bNrnOu524r7Y34oRRWFJcZ77KWWhpuJ-bJVWUSTwvJLgVMiCfaqI6DZr05d6TgN53_2IUZkG-x36pEl6YEk5wVg_Q1zQdxFGfDhxPVj2wMcMr1rGHuQADx-jWbGxdG-2W1qlTGPOnwJIjbOpVmQaBc4xRbwjzsltmmrws2fMMKML5jnqpGdhyd_uyEMM0tzMLaMISv3ifxS6QL7skie6yj2qjlTMGwB08KoYPD6BUOiwzAldRb_3y8mP6Mv9p7oApay6BoniYO2iRrK31RTZ-YVPtey9eIfuwFEsDjW3DKBAKmk2XFcCdLq2SWcUaNsQ",
"kty": "RSA",
"use": "sig",
"kid": "smoff-key"
}
},
"token_type": "Bearer",
"expires_in": 3336,
"client_id": "OAuth2Client",
"email": ""
}
The RS can then leverage the cnf_key value to do some additional and optional, out of band cryptographic challenge with the presenting client, to ascertain they are in possession of the corresponding private key pair.
The powerful use case is the ability to validate that the client submitting the access_token, is in fact the same as the original recipient, when the access_token was issued. This can help reduce MITM and other basic token misuse scenarios.