Have you ever had a notification about a suspicious login attempt from a digital destination you’ve never been to? Hopefully it came with the option to say it wasn’t you, allowing you to deny access to that specific place and rebuff the user trying to sneak into your account or information. If so, you probably have token revocation to thank for the security measure.
Token revocation means a token is no longer able to be used for access to a protected digital place, and it’s often behind the scenes in the denying process. It’s similar to session revocation in that you’re blocking access at some level, but there’s a key difference. With session revocation, you can deny one or more sessions and still access protected information. But token revocation is more permanent because it “kills” the token that might otherwise be reused for the duration of the token’s lifetime.
Tokens play a big role in OAuth 2.0, which is designed to protect resources from wandering or malicious hands by using tokens to securely authorize users. You could build your own method of verifying access tokens and get a decent way there with open source packages, but a ready-made solution—token introspection—is easy to use and gives you the ability to offload the work from the app team to the identity platform’s team. PingOne for Customers handles the messy job of building a token verification system by giving you an API endpoint that does the work for you on our backend. In this blog post, I’ll walk you through how to use token revocation in PingOne for Customers.