Cloud service companies are widely adopting OAuth 2.0 & it's a great concept that provides a less riskier method for cloud services & app developers to provide a Single Sign-On experience for their users. OAuth enables developers to offer users an easy method to allow “trusted” apps to perform transactions in their cloud based services and applications on their behalf. For example OAuth enables a user to authorize an app like LinkedIn to post a Tweet on the user's Twitter feed on behalf of the user.
Now back to my issues with how providers are implementing OAuth and the annoyances being caused by customized deployments. Most of my annoyances primarily relate to variations between provider refresh & access token policies. The OAuth 2.0 spec is based on refresh & access tokens which are required to perform transactions on a user's behalf. Access tokens are temporary tokens that must be included in all requests & transactions committed against an OAuth provider. Once issued these tokens generally last less than an hour. Once these Access Tokens expire a Refresh Token is required to gain another valid Access Token which will allows continued access until the new Access Token expires & the Refresh Token is used again to retrieve another Access Token and the cycle perpetuates in a loop.
So my primary annoyance relates to the inconsistencies between providers regarding their Refresh Token policies. The Refresh Token policy that is vexing me at the time of this post is related to how some major cloud storage providers administer their OAuth Refresh Tokens. Most OAuth providers issue a Refresh Token that is permanent and won't expire until revoked by the authorizing user. Having this permanent Refresh Token definitely fosters a bit more risk & vulnerability but I'm not convinced there is much more risk compared to the more annoying policies.
I'll describe the annoying Refresh Token policy. In the interest of security some cloud providers have implemented a more locked down policy on their Refresh Token policies and here is the flow. Ready ?:
- App requests a Refresh & Access Token from provider
- Provider Responds with a Valid Refresh & Access Token
In this flow, we have our valid Refresh Token but this token is under a more restrictive policy which generates the token as a ONE time use & expires after 60 days. This means when the Access Token expires you have to use this (One time use) Refresh Token to get another Access Token. Now we do get another Refresh Token with our Access Token request but again that is a one time use & 60 day expiry.
You maybe asking, What's the problem? Well this policy presents some unnecessary issues for developers that have to build against this policy. This particular policy doesn't provide the developer a friendly method in providing a seamless SSO user experience within their apps. In most scenarios, developers will have to persist Refresh Tokens (hopefully encrypted) in their apps data store. With a permanent/long life Refresh Token developers can easily implement a seamless SSO in their apps and don't have to struggle with figuring out a whole strategy on tracking the life of Refresh Tokens. I feel this restrictive policy is futile and doesn't add any value or real security. It just feels as an illusion so that companies can sell as security proposition or differentiator.
In conclusion I'm all about security but I'm also down with being sensible when designing & implementing security policies. If you produce tools & services for developers you really need to seriously weigh & balance the very thin lines between security & overall usability. At the end of the day the reality is that we can hack solutions for these types of constraints but why do companies feel the need to complicate things for the very community they're trying to capture & maintain?
So if you're a cloud service provider using OAuth please use sensible Refresh Token policies. It really does make huge difference in a developers life :-)