On Thu, May 6, 2010 at 6:36 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > Marius > >> Isn't this taken care of by the scope? > > I don't think so. It looks similar to Google scopes > (http://code.google.com/apis/gdata/faq.html#AuthScopes), but nothing like > Facebook scopes > (http://developers.facebook.com/docs/authentication/permissions). > > >> I assume the requested scope is associated with the issued access token. > > I don't think we should require client apps to know all the sites a service > uses for its resources (even those in a given scope) at the start of the > flow. It kills interop for clients without much service-specific knowledge. > It also constrains how services arrange (and re-arrange) their resources. > > What should a client do when, on accessing a protected resource, it is > redirected to another site? > Does it send the token to the new site? > Sometime sending the token will be dangerous — the other site shouldn't see > these confidential tokens (eg https://api.example.com -307-> > http://cdn.net/236423). > In other situations the token should be sent as the same service control both > sites equally (eg https://api.example.com -307-> https://account.example.com). > > > As a concrete example, access the Facebook API such as > https://graph.facebook.com/btaylor?metadata=1 and the response lists dozens > of other URIs. Most of the URI are on the same site > (https://graph.facebook.com) so presumably a client app can send the same > token. Another URI is at a related site (http://www.facebook.com), but > doesn't use TLS. Even if an app could tell this domain was "related" it > probably shouldn't send the same token. If one of the listed connections was > to an external site (eg "blog":"https://blog.example.org";) I would assume the > same token should NOT be sent. > > The app needs to be given the list of sites appropriate for its token to make > these decisions safely. > > >> It is up to the sites accepting the access tokens >> (the protected resources) to verify and enforce the scope. > > A site cannot prevent a token being sent from a client app to the wrong site, > because the right site never sees the traffic.
I see what you mean. As David commented, not sure if this is a problem in real life. The resource that the client is trying to access should not redirect to an untrusted resource which is not supposed to receive access tokens. If the resources responds with a redirect I think the client should trust that and just do it. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
