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 :-)
Thx
-a
Comments
Post a Comment