This description actually sounds a lot like the user-agent flow (aka, "implicit authorization grant") in OAuth2 more than it does a true two-legged system. The user is still there, and there's still a client and protected resource, it's just that they're fairly tightly tied.
When using the implicit flow, one of the things you rely on for verification of the client is the callback url. In this case, it can be completely pre-registered back to something that the AS/PR has direct control over. If you wanted to do a more traditional two-legged approach, you can use the client-credentials flow between the two servers and have the user's identity just be asserted as part of an explicit API call. But since you have a user in the loop, you might as well use them and do a real three-legged kind of thing. Additionally, the "user is logged in" bits could be handled by using OpenID Connect if he wants to go in that direction. At a very high level, the user ID basically becomes an OAuth2 protected resource, thus allowing you to log in from any where you can get an access token. (Connect folks, please feel free to chime in and tell Justin how wrong I am.) -- Justin On Wed, 2011-08-31 at 15:14 -0400, Peter Saint-Andre wrote: > I tried to help Justin off-list, but it would be nice to have a FAQ > somewhere that shows developers how to translate from OAuth 1.1 to OAuth > 2.0, even just conceptually (as in, "they got rid of the legs, how do I > do two-legged auth in OAuth 2.0?!?"). > > On 8/26/11 5:04 PM, Justin Karneges wrote: > > Hi folks, > > > > I currently use a proprietary token approach to provide authentication to a > > browser widget, and I wonder if OAuth could be used to replace it. > > > > Here's how the system currently works: > > - website supports authenticated users (happens via username/password > > form) > > - website and widget provider have a shared secret > > - the website serves a page to the browser, containing an embed of a > > remote > > widget as well as a token that asserts the currently logged in user. the > > widget takes this token and performs an ajax call to the widget provider > > server. behold, the user is now logged in to the widget. > > > > In trying to organize this into OAuth terms and roles, here is what I come > > up > > with: > > - resource owner: the user > > - resource server: widget provider (where the resource is generically > > "the > > ability to utilize the widget") > > - client: the webpage running in the browser > > - authorization server: the website > > > > The website essentially serves up the client application and token in one > > shot, so the client never has to explicitly ask for a token. However, the > > client would then take that token and use it to access a service. The > > website > > and widget provider would share key material such that token validation is > > possible, but it's important to note that the two services are not owned > > and > > operated by the same people. > > > > Does this seem right? Normally when I think of OAuth, I think of a user > > giving a third-party service access to his personal stuff, but in the above > > flow > > I'm proposing that OAuth be used so that the user gains access to his own > > stuff. In fact, there would be no way to access his stuff other than this > > approach, so it's not just about optional third-party access. It's the > > direct > > and only access. > > > > Would love confirmation that OAuth is appropriate for my needs, and if I > > have > > the roles right in that case. > > > > Thanks, > > Justin > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
