Hello fellow Stormpath developers! Today I’m officially announcing the latest 3.0 release of our Express-Stormpath library, and I’m very excited about this one!
In 2.x we began our effort to use OAuth2 access tokens and refresh tokens as a mechanism for browser authentication. We’ve found that developers love this feature, especially because the Stormpath REST API will manage all the token state for you, and you can revoke tokens with a simple click in our Admin Console!
However we often received this question: because the tokens are cryptographically signed, can I skip the token verification round-trip to the Stormpath REST API? You bet! This was always possible with the local validation strategy option, but in 3.0 we’ve made local validation the default.
We also refactored our middleware chain, to not attempt to resolve the current user unless you’ve explicitly requested a resolution with the getUser middleware. We made this change because it was too easy to accidentally require authentication on your public asset routes, and this could cause a serious slowdown if your front-end needs to request a lot of assets during bootstrap.
We’ve finished our JSON API implementation, making it easier to connect your front-end or mobile application to Stormpath (yes, we now have support for iOS and Android!). The 3.0 release now has a complete Registration JSON API and a Login JSON API that provides a view model of your registration configuration and social login configuration. We’ve also standardized our error response structure, so it’s easier to handle exceptions in your front-end or mobile client.
These are available in our follow-up minor release, 3.1.0. These new handlers are my favorite new features in the library, because they allow you to achieve custom flows, such as:
- Assert that a user’s email address is on a permitted domain.
- Add extra data to the account when it is being created.
- Delete custom session cookies after the user logs out.
I’m sure there are many more reasons why these handlers will be useful to you, and they are also a step in the right direction for us as we add Multi-Tenancy Support to this library in the coming months.
When we moved from 1.x to 2.x, we introduced a few options and configurations that helped us make the migration, but in the end were kinda silly. The biggest issue was the “website” option: you had to use this option to turn on a lot of the default options of the library. The idea was to segregate the HTML features from the JSON API features. In 3.0 we’ve deprecated this option, in favor of vanilla content negotiation.
In 2.x we also required that you wait for the “stormpath.ready” event before starting your server. This was super annoying for everyone and we’ve removed it in 3.0, you can now start your server whenever you want and as soon as Stormpath is ready we will serve the requests that we need to.
The 3.0 release does a lot by cleaning up the library options and exposing better APIs, but we’re not done yet! In the coming months we will be working on the following features:
- Multi-Tenancy Support – Using our Organization Resource, you will be able to require the user to identify which Organization/Tenant that they wish to register for or login to.
Learn more about Stormpath Multi-Tenancy
- More Authentication Middleware. Right now we make it easy to assert that the user is logged in, with
loginRequired, or that they have an API Key for their account, with
apiAuthenticationRequired. But Stormpath offers many ways to authenticate, such as HTTP Basic Authentication. We will be refactoring our authentication middleware to expose the different authenticators.
Stay tuned, and happy coding!