OAuth.tools Exits Beta
This week, OAuth.tools exited beta. It's an important step in the app's life cycle, and I'm very glad to have come to this point. In case you haven't been a part of the journey though, let me first explain a bit about what it is, and then tell you some of the things we have in store.
OAuth.tools is a Web application that allows users to learn about the various flows involved in OAuth and OpenID Connect. It was born out of a need to demo all of these to prospective Curity customers in a coherent, understandable manner. Previously, we had been using a Python Web app together with Postman. This worked, but it required a lot of context switching, making it harder for the viewer to follow. The old tool was also constrained to certain flows that we often demoed. As the Curity Identity Server added support for more and more flows, we needed something more generic.
The initial commit came in almost exactly two years ago, and the tool was published online some weeks later. It took a while for those of us who didn't code it to grasp what it was at first. Eventually, the idea sank in though: it was Postman for OAuth ☺ (If this isn't enough to turn on the light bulb, checkout this intro video.)
With this, we could make all sorts of flows. Today, this has expanded into an almost-exhaustive set:
- Code flow
- Implicit flow
- Hybrid flow
- Refresh token flow
- Introspection (with/without JWT response type)
- Encode/decode JWT
- Device flow
- Client Credentials (CC) flow
- Resource-owner Password Credentials (ROPC) flow
- User info flow
- Call API (so we never have to use Postman ☺)
There were a couple issues though:
- We all needed to connect our locally-running instances of Curity to this new Web app.
- We all had different issuers, clients, keys, etc.
The first was easy to solve using Ngrok and a little script. Ngrok tunnels local processes (like Curity) to the public Internet over SSL. This would allow the OAuth.tools Web site to communicate with our local instances of Curity.
The other issue we needed to solve was the disparate configuration of our respective Curity instances. This was solved by allowing the user to configure an "environment", a concept we obviously borrowed from Postman. (We're gonna give it back later.) With these, we could all point to our own OAuth server and configure our own clients. We could even create many and share them around. You can read about how to setup a new environment on Stack Overflow and see it in the following screenshot:
Demo and Updates
With all this, we were ready to run our demos, and that's what we've been doing for the last couple of years. This provided us with a great chance to eat our own dog food, fix bugs, and add helpful features. During the beta, we added tons of new features like:
- More and more flows (e.g., logout and the ability to call an API)
- The ability to query the OpenID Connect provider for various claims using a pretty slick editor:
- Ability to introspect a token with a different client than the one that requested it
- Possibility to provide a login hint
- Proof Key for Code Exchange (PKCE) support
- We ran all the OpenID Foundation's Relying Party (RP) certification tests and fixed the issues that we found.
- Ability to import/export all flows and environments
- A share feature that allows you to securely send your config to a friend
- Many, many more
By now, the beta was starting to feel like GMail's (if you remember how long that lasted). It was actually an ideal time to remove the pre-release moniker.
A while ago, we submitted OAuth.tools to API World's 2020 API Awards. They notified us last week, that we won the best in API security award!
At the same time, we added a new Playground button that can be used to create a new environment in the app; this can be used in any of the flows with a test instance of Curity. When landing on the site with no config, a bunch of flows are preset and integrated with this playground. This makes it possible to start using the flows and learning about OAuth and OpenID Connect without needing a server. If already setup, it's easy to add the playground environment without disrupting any existing configuration as well.
Another recent event was the creation of the oauth.tools tag on Stack Overflow. With that, users can now create questions in a way that we can more easily find and answer them.
With these milestones reached and all the years of bug testing and enhancements, we figured now was the time to leave beta.
Of course, we're not resting on our laurels. We have big plans for OAuth.tools such as:
- Support for token exchange flow
- Pushed Authorization Requests (PAR) capabilities
- Certificate-constrained tokens
- JWT assertions as a credential to authenticate clients
Basically, more and more advanced stuff.
If you have suggestions on features or run into issues with this tool, let me know on Twitter.