Awesome New Stuff
The 2.0 release wraps up two weeks of improvements to the OAuth 2.0 Web console. A refined UI, based on experience from daily usage, a number of bugs squashed, and the addition of fancy charts for that extra “ooh look at me!” effect. Also, I find them quite useful. You can also manage client application access scope from the Web console, see below for why this is so important.
Based on the Web console and soon-to-be-released new app I’m working on, I extracted a Sammy.js plugin for OAuth 2.0.
There are cases when you’ll need to manage access tokens/grants directly from your application. For example, an app I’m working on right now let’s you signup and implicitly creates an account, granting you a new access token. There’s also username/password access, and if you forgot your password, it will email you a one-time access link, embedding an OAuth 2.0 authorization code (essentially a single-use token exchangeable for an access token).
I rolled all these common uses into a simple API, by making them available as class methods of Rack::OAuth2::Server. Adding documentation and usage samples could surely help. If you need to register client applications from your code, or change existing registrations, that’s also easier now with the register method.
Security Issue With 1.4
While working on 2.0, I find a potential security issue with 1.4. I strongly urge you to upgrade.
Prior to 2.0, I made the assumption all client applications would want access to the same scopes. The allowed scopes are listed in a global setting. Of course, you may want to grant some clients/users additional scopes. If you’re using the OAuth Web console, you’ve been granted access to the scope oauth-admin. There are clear instructions how, from your application, you can allow only administrators access to the oauth-admin scope.
The problem is, any client application can request access to this scope. Only administrators can grant it, but an unwary administrator running low on caffeine, could inadvertently grant access to some rogue client requesting this scope. That’s a problem.
That’s all fixed now. Since 2.0, client applications can only request access to a scope they were registered to have access to. Since you’re only going to register one client application with that oauth-admin scope, only that client is allowed to access the OAuth Web console (and likewise for any other admin-only resource you want to protect).
To help manage client applications, the OAuth Web console makes a clear separation between common and uncommon scopes. Common scopes, those you grant to every client applications, are listed in the Admin settings, will be set on by default for each new client, and you can check them on/off from the UI. Uncommon scopes, the ones only granted to special few clients, are not listed anywhere. You can enable them for individual client applications by typing the scope name and they will show in red.
Migrating From 1.4 to 2.0
Internal changes, improved API and new way of limiting client application scope, means 2.0 is not backward compatible with 1.4. But you already guessed so from the bump in major version number. Migrating should be fairly simple though.
To upgrade your database from 1.4 to 2.0, simply run the migrate task:
1 | $ oauth2-server migrate --db |
You will then need to edit existing client applications and grant them access scopes, which you can easily do from the new Web console, or using the register method.
If you used the Rack::OAuth2::Server class methods before, you’ll notice that some of the method names have changed, and so did their signature (in particular, access_grant and token_for now return the code/token respectively.