OAuth2, Clients and Authentication Grants
Apr 15
One of the things that I really like about our approach to server authorization is that we’ve elected to get completely behind the OAuth2 specification.
Cloud CMS provides support for all of the OAuth2 flows. We provide an authorization and resource server so that you can separate concerns and perform the full three-legged “auth code” flow. Or you can simplify things and use something like a “password” or “implicit” flow depending on the security environment of your application.
For environments like HTML5/JS, we continue to recommend (rather strongly) that you employ a full untrusted “auth code” handshake.
When we started out, we briefly dabbled with OAuth 1.0 before realizing that it was tedious to use (much less implement). Signatures needed to be computed and passed along with every request. This meant that if you wanted to serve assets out of the repository directly, information would have to be either encoded within URLs or it would need to be available as a cookie. And if you were going to store a cookie, then you had to implement some kind of server-side token registry with expiration and refresh in order to offer any kind of assurance of fidelity. However, to do so meant that we’d be drifting from the spec and doing our own thing.
Fortunately, lots of other vendors were noticing the same shortcomings of OAuth 1.0 (not really shortcomings, per se, but definitely things that were not within the bounds of the specification to address). OAuth2 represents a best effort by Facebook, Twitter, LinkedIn and a whole host of other vendors to address many of the issues we found we needed to deal with.
Cloud CMS - Clients
We decided early on that we wanted platform owners to be able to create as many OAuth2 “client” key/secret combinations as they wanted. That way, they could provision client/keys on a per-application basis. Or they could have a single client/key service a whole bunch of applications.
Furthermore, if for any reason a client/key combination were compromised (as in, some hacker out there figured out your client secret), you could monitor this, identity it and then shut down the client. Create a new client key/secret, issue it and away you go.
Thus, we let you manage as many client key/secrets as you’d like.
In addition, we let you define on a per client key/secret basis what kinds of features or flows you’d like to enable. You might restrict certain clients from participating in an untrusted client flow (like the “implicit” flow). You can just toggle this stuff on and off.
Cloud CMS - Authentication Grants
Another feature that wanted to implement is what we can “authentication grants”. These are basically alternative “username/password” combinations that you can grant to a principal running on a specified client. Sounds kind of complicated, right?
The idea is that you often have a mobile app that just wants to sign on to Cloud CMS as a user. You set up the user ahead of time. The user might be called “app”. To sign on, you need to send username and password information over the wire.
Anytime you send password information over the wire, there is a risk. We fallback to HTTPS (SSL), so the risk in transport (i.e. over the network) is minimized. OAuth2 requires SSL for this very reason.
However, there is still a risk in the application code itself. What if someone could crack it open and see what password you set up? Fortunately, this isn’t very easy to do with compiled application code like native iOS, Android or Appcelerator Titanium code.
But there is a really big problem if you’re using HTML5/JS running the browser. Basically, anything running in a browser is completely snoop-able. You don’t have to be a really proficient “hacker” to open up the source code of the application and find the embedded passwords in the <script></script> blocks.
We provide a few tools to protect against this.
One is to create an Authentication Grant object which provisions alternative credentials (a key and secret) that can be used to authenticate as the “app” user against a specific client key/secret combination (and only that combination). That way, if a snooper were to figure out the Authentication Grant secret, they’d still only be able to use it for a) the “app” user and b) for that specific client.
Thus, if you detect foul play, you can shut down the Authentication Grant. Worst case, they gain wrongful access to that one user on that one application. The upside is that they can’t gain greater access to your platform. They’re constrained, you can detect it, and shut it down.
Another tool is to specify valid Domain URLs from which token-requesting authorization calls are allowed to arrive. You can constrain those who wish to authenticate for a given Client or Authorization Grant so that they must arrive from a specified set of Domain URLs. That way, if someone tries to use your Authentication Grant username/password for a completely different application, it won’t work.
This works but it’s also pretty easy to trick. HTTP headers can be manipulated and things like that. However, it’s a good safeguard and yet another way that you can detect foul play.
Finally, we offer auto-provisioning of Client keys and Authentication Grant keys running in an implicit “untrusted” capacity. If you use any of the Gitana drivers, you can elect to have the appropriate client/auth keys sent to you when you connect. These can then change once application deployment or even once per-connection. This is really the most full-proof way to bolster security for HTML5/JS applications.
It should also be mentioned that in all cases we fully support OAuth2 refresh tokens and expiration of access tokens. So all the while, the client code must re-assert the validity of its tokens which offers all kinds of chances to detect and stop tokens from being tampered with.
Cloud CMS supports OAuth2 for everything in its REST API and provides convenience functions with all of its drivers so that connecting and working with Cloud CMS is completely transparent. You normally don’t have to deal with any of the OAuth2 capabilities under the hood. But, should you need to, we’ve really given you a good engine so that you can ensure the security of your mobile applications.