Hi there
So today, we are going to talk about OAuth2 Proof of Possession.
Let’s get started :D
Say Hi to Tim again. Some of you might already know Tim from our earlier post on Adaptive Authentication. But hey, life is too hard to remember badly drawn stick man figures from the internet so here you go.
This is Tim.
Many don’t know this but Tim comes from a fabled family (who are now in ruins, unfortunately) that once used to rule the kingdom of Fairyland. So, today’s story is going to be about Tim’s great-great-great-great-great-great-great-great grandfather, King Thomas.
King Thomas was famous for his benevolence and wisdom and he ruled justly. So, the kingdom was rich and prosperous, people were happy, and all was well.
But king Thomas (we’ll just call him King Tom from here on out) was getting very old and frail.
King’s only son, Prince Timothy was out on a quest to prove his worth of Knighthood and was not to return until the winter was over.
Being so old and weak, King Tom feared that this would be his last Christmas. So he wanted to secure the crown jewels before he passed away until Prince Timothy; the heir to the throne, returned from his quest.
In the kingdom of Fairyland, the crown jewels was a symbol of power. And whoever had the crown jewels in possession was deemed to be the ruler of the kingdom.
King Tom feared that upon his passing, someone would stage a coup and seize the crown jewels. Thereby claiming the right to the throne. So, until prince Timothy returned, King Tom wanted to safeguard the crown jewels.
So, he ordered a chamber to be made in the castle to keep the crown jewels. His men built the most secure chamber in the kingdom with iron walls and a steel door which no one could break into by force.
But there was a problem.
Like every other ordinary door, this door too had a key.
Now, King Tom began to wonder.
“What if someone stole the key?”
“What if someone replicate it?”
“What if the key has already been replicated!?”
These questions troubled the old king’s mind.
The king wanted the key to be special so that only his son, prince Timothy would be able to open the door with it. So, with no answer in sight, he turned to his trusted adviser, enchanter, and wizard, … “Sterling”. (No pictures of Sterling, sorry)
After hearing King Tom’s troubles, Sterling told the king, “Your majesty, I shall cast a spell on this key so that only the true heir, the one with your blood can use it to open the chambers”.
The king was delighted!
So, Sterling cast a spell on the key and made it so that the key would unlock the door to the chamber only if it was used by someone in king Tom’s bloodline.
Now, only the true heir, the one with King Tom’s blood, could use this key to unlock the door to the chamber with the crown jewels. And now the crown jewels were truly safe.
Now you might be wondering what this bedtime* story has to do with OAuth2 proof-of-possession. Right? (* Anything you read in bed qualifies as a bedtime story. The more you know.)
If you think of OAuth2 bearer tokens, they are very similar to keys. Much like keys unlock doors to treasures, crown jewels and whatnot for its holder, OAuth2 bearer tokens grant access to resources and all the privileges associated with that token to its bearer i.e. the entity that has the token in possession.
If a key is stolen or forged, then anyone who has the stolen key can open the doors the original key was made for. And very much like keys, if a bearer token is stolen or replicated, the bad guys can use the forged or stolen token to impersonate the original user and obtain access to whatever the resources or the privileges that token was minted for.
Only if there was a way to secure these pesky bearer tokens to ensure that only the intended person can use it. Like the key King Tom made which could only be used by his son.
hmmm…
King Thomas had to resort to witchcraft to make that possible. But in the OAuth2 world, we already have a way to ensure this behavior.
It is an enhancement on the OAuth2 protocol. And this concept is called the OAuth2 proof-of-possession. With the concept of proof-of-possession, we can get something called bound tokens.
So, when you want to get a bound access token, you will provide a little bit of yourself, a little bit of DNA to the Authorization server. And the server will bind that DNA into the token that is minted for you and present it. In our story, King Tom did this by binding the key to his bloodline with witchcraft so that only prince Timothy could use it. In the OAuth2 world, we use the public key of the client for this.
So, when you want to get a bound token, you will provide your public key to the Authorization server, and the Authorization Server will bind that public key to the access token that is issued to you.
Well, now you might ask, how do we send the public key to the Authorization Server and make this binding work. Well, for that, there are a few different ways. Like Mutual TLS, Application level PoP tokens (DPoP), clients assertions, etcetera. Mainly, etcetera. And that is a story for another day. 😉
Right.
So now when you take this bound access token to the resource server, the resource server can challenge you by asking you to provide proof that you are the actual owner of this token. It would do this by asking you to verify that you have the private key (which something only you would have) of the public key that is bound to this access token. Again, the way it happens can differ. OAuth2 Mutual TLS is somewhat of the industry standard for this. And for SPAs, there is application level PoP tokens.
By doing so, we have now ensured that these tokens cannot be stolen, replicated and misused by the bad guys, much like how King Tom made sure his key cannot be stolen and misused.
So, that’s it for today. Congratulations on reading thus far. I hope you now have somewhat of an idea what OAuth2 proof of possession is.
Bye!
