The group was looking at the issue of UI complexity and features like "Share" buttons–a user clicks on a "Share" button and passes a token on to friends and family members to share content such as photos. Is this an appropriate use of OAuth? Are there complex token handling and UI issues to resolve?
The conversation took a rather interesting turn when Chuck Mortimore (Salesforce.com) commented that there are some technical SSO and session management issues to be concerned about. Bob Blakley (Gartner) responded by saying, OAuth is being used to establish CORBA-like "associations" to handle the absence of session management. The idea being that OAuth enables a different form of re-authentication for token holders than would normally happen for a typical user.
Bob asked: Are we overloading session management on to OAuth?
Because OAuth gives applications an idea of a separate identity from the user, access control systems can make different access control decisions about an authorized agent (token holder) distinct from the user that authorized agent (token holder). The implication is that a OAuth agent application could have a different session life than the end user. In contrast to OpenID and other SSO approaches, activity can take place without the presence of the user.
In my personal opinion, whether intended or not, enabling authorized agent session management independent of user session management is OAuth's most powerful feature! It allows for agent specific access policies and independent session lifetimes that will work in far more use-case scenarios then currently offered in current Web SSO protocols where the focus is on solving user-present in the browser scenarios.
But there is some caution here. Bob quite correctly pointed out that the fact that people are doing this without it being intentionally designed may be good reason to be worried. The group agreed that though implementations seem to be handling it well, there is good motivation to work further on some good guidance on refresh and re-authentication issues within OAuth.
2 comments:
I think the issue of practicality and deployment is the hardest to overcome here, really. Authorized agents can enable great new use-cases, but our notion of session management largely depends on browser-like scenarios.
In the browser, it's easy, right? The party doing the authorization can rely on session established from a service provider, as the connection starts with the user themselves.
To connect, say, two 3rd parties to share information on behalf of the user, that context needs to be established elsewhere. Deploying a system like that, even with a smart agent to bridge the gap, requires more than just an access token. It's solvable in a number of ways - but no solution really has a minimal amount of integration issues for, say, an IT admin to enable their company portal to access Google-hosted user data.
For that scenario, which is what I think is the really interesting one, we can use OAuth to manage the endpoint fetching, the agent authorization, and everything in between. But setting up the user context in a connection originating from a company portal instead of a user's browser means some custom code *somewhere*.
One place to look is at the use cases currently described in the V10 draft. https://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/
Oracle has been concerned about issues around strength and security of tokens. But it is clear that there is some good potential here to build on. One of the biggest issues is to figure out is when and how best to bind bearer tokens with authorized agents when needed.
Post a Comment