Hi David, > I guess the way that we solved this was having the Protected Resource > include the access token in links as applicable.
Yes, I noticed Facebook did this in some actual responses (though I don't think I saw it documented). I don't personally think it is a great architectural choice, but I guess it works for Facebook today. I hope that isn’t the only approach feasible with OAuth. Including tokens in links does not work if you want to use the Authorization HTTP header -- which offers some security benefits, and is part of OAuth. It doesn't play that nicely with other aspects of the web architecture (such as caching, etags, conditional requests, bookmarks...) as all the URIs change for each client/user/refresh. The server also has to dynamically generate each page for each token. It puts secrets in places where they might not be expected. Do Facebook apps know that exposing the content of a protected resource or exposing a link it contains also exposes their secret token? That doesn't happen with other authentication schemes. Tokens in URIs will end up in more logs and search engine indexes etc. > We don't do cross site access tokens Are you sure you will not in the future (perhaps after a merger or acquisition)? > and I'd hate to see us standardize this more complex use case Its not very complex, particularly if the default value for "sites" was the site returning the token. Facebook wouldn't have to do anything! Even Facebook-specific apps could ignore any "sites" field and just hard-wired a rule to use a Facebook token on initial requests to https://graph.facebook.com URIs and that's all (assuming Facebook says that is how their API is designed to work). > Do you have an implementation with this problem that we can look at? The whole Internet is a web of links across security boundaries. I don't have a specific OAuth implementation to champion this issue. -- James Manger _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
