OpenId, OAuth, and more: A New Specification is needed!
My next post partially recants some conclusions of this one. By all means read this, and when you're done, please continue over to the follow-up post. Thanks for being my guest!
The development and use of web applications is growing rapidly. Several tools, such as Ruby on Rails, have made it increasingly easier and more natural to use the web for purposes of tracking, managing, administering, creating, and getting things done. Using this market platform, the big companies (Google, Yahoo, Microsoft, etc) have been emerging with a success superior to the segmented community as a whole, because they have enough resources to create a number of quality web apps and connect them together in intuitive ways. We at Sabretech Consulting, LLC have determined that the key element that is needed for the community (as well as the big guys) to reach this emerging market platform effectively, is a standardized and secure way to connect apps to apps, for a user to use common identities and offloaded permissions management. OpenId and OAuth have taken steps toward this seamless and secure integration, but on the scale I am thinking of, they (and OAuth particularly) become inadequate. Let me explain:
OAuth allows one web app to communicate with another web app to access and modify a user's data. Though the protocol is good for a one-to-one purpose, it becomes inefficient at the next stage, where several applications are involved. With OAuth, every application involved must keep track of permissions for its own data in respect to every other connected application. This is where the inefficiency lies -- I in fact hold this to be a fault of philosophy: OAuth assumes that the hosting application is the owner and authorizer of the data it holds, where in fact it should be the User who owns and controls that data.
In keeping with the philosophy where the User controls their data, I propose that a new specification is made, similar in workings to both OpenId and OAuth, but separate and distinct: a specification for the decentralized control of permissions. Just as OpenId has achieved decentralization of authentication, we need a decentralized control of permissions. When this is used alongside OpenId, it would complete our thirst for privatization AND integration!
Imagine a group of web apps (I would call it an "app cloud"), each created by different developers, using these new standards. This is how I see it happening: A User could navigate to app1, and log in with his/her openid_url. The OpenId server verifies the user's Identity to app1. It also gives app1 a 'permission-to-act-as' token, which includes the openid_url and a permission key. However, app1 needs to use some data that is stored on app2. app1 can ask the user's Permission server for permission to use data from app2. To to so, app1 sends its 'permission-to-act-as' token to the User's Permission server, which then verifies the token with the OpenId server, and then grants permission via a 'permission-to-use' token, which includes the permission server url and a permission key. App1 sends this token along with its request for data to app2, which then needs to verify nothing but the 'permission-to-use' with the User's Permission server. Though not necessary, it would make good sense for the Permissions server to be one and the same as the OpenId server, so it would be good if they can co-exist at the same url.
Follow-up: Basically stated, perhaps a new specification is not needed. OAuth may be sufficient. My point, hopefully, is that there are needs that must be addressed, and should be done right. Read more about this in the next post.
2 comments:
There is no reason why this cannot be supported within the existing protocols. OAuth can easily be made to share an Access Token among multiple Consumers. At the end, what you are proposing will create less security and control. Putting the user in control means giving the user all the information about how their data is going to be used upfront.
Sure, an OAuth-enabled app could share the same Access Tokens among multiple Consumers, and in fact that may be what we'd be doing -- the difference lies in where the permissions are controlled. Instead of each app knowing which other apps have what permissions, the apps can register with the Permissions server what data types they have, and the user can then choose how private or public that data should be. I don't want to have to explicitly give permission from each app to each other app -- I'd rather set generic permissions on my data itself. FaceBk essentially does it this way with its apps (about the only right thing they did on their app platform). Say on a photo site, I want to simply specify that only I can manage photos, anyone can view them, and I trust any site that I'm logged into that tries to read them. Now that I think about it though, any OAuth app could just as well use generic permissions instead of specific -- as long as the user knows what's going on, of course. Maybe I'll post again outlining the power of OAuth once used in a more user-friendly way.
Post a Comment