Is a pop token more secure than the bearer token?
I tried reading a few articles, however I'm not able to understand the merits of POP over Bearer token. A Bearer token if lost (during transit over the wire) can give the holder of the token the same privileges as the genuine owner. POP token is supposed to provide additional security by making sure that it has a component that is known only to the genuine owner. I'm not able to understand when this component comes into use. Is it during token generation? If so, the final token cannot be any more secure than the bearer. If this is used during token validation, how is the target supposed to know the secret?
There are a couple different types of proof of possession (Pop Token) , but let's take the kind that uses an asymmetric key pair. In this case, the authorization server and the client agree on an asymmetric key pair that represents the client (either side can generate this key pair) and the authorization server issues a token that represents the authorization for this client and contains the public key.
Then, the client can make a request to the resource server and sign the request with the private key, including the token the authorization server generated. How that's done isn't specified in the latest Internet-draft, but it can be done in several ways. Usually this will include a nonce or timestamp to prevent replay attacks.
Now, the resource server can verify the request using the public key in the token and verify that the token authorizes the client to use that key pair, but because the signature is asymmetric, if the token and signature are compromised, then nobody can forge subsequent requests, since the signature doesn't leak the private key. However, if the user had used a Bearer token, then the entire token would be leaked, leading to forgery.
This could also be used where there's a shared secret, such as an HMAC key, and the authorization server issues an encrypted token that includes this key. The resource server could then extract the shared key by use of the authorization server.
Then, the client can make a request to the resource server and sign the request with the private key, including the token the authorization server generated. How that's done isn't specified in the latest Internet-draft, but it can be done in several ways. Usually this will include a nonce or timestamp to prevent replay attacks.
Now, the resource server can verify the request using the public key in the token and verify that the token authorizes the client to use that key pair, but because the signature is asymmetric, if the token and signature are compromised, then nobody can forge subsequent requests, since the signature doesn't leak the private key. However, if the user had used a Bearer token, then the entire token would be leaked, leading to forgery.
This could also be used where there's a shared secret, such as an HMAC key, and the authorization server issues an encrypted token that includes this key. The resource server could then extract the shared key by use of the authorization server.