Redirections are a bad example when used with an access token in the query parameter...
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of David Recordon > Sent: Monday, May 10, 2010 6:34 PM > To: Manger, James H > Cc: OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] sites with wildcard > > Hey James, > I guess the way that we solved this was having the Protected Resource > include the access token in links as applicable. We don't do cross site access > tokens and I'd hate to see us standardize this more complex use case > without real world deployment experience. > > Do you have an implementation with this problem that we can look at? > > Thanks, > --David > > > On Mon, May 10, 2010 at 5:31 PM, Manger, James H > <[email protected]> wrote: > > Yaron, > > > > > > > >> I don't understand the scenario that requires this feature. When does > >> someone ask for a token without knowing where it is going? > > > > > > > > Example: > > > > A client app gets a token to make an API call to a protected resource > > that returns an Atom feed. > > > > The feed contains lots of entries, with links to photos, style sheets, > > and scripts. > > > > The client app gets the photos. > > > > > > > > Should it send the token when getting the photos? > > > > > > > > On service A the Atom feed and the photos are all served from the same > > HTTPS host, with the same protection, so the token must be sent. > > > > > > > > On service B the photos are hosted on a separate outsourced content > > distribution network. The photos are protected by using long > > unguessable URIs (the URIs are effectively "capabilities" to read the > > photos). The token does not need to be sent. > > > > > > > > On service C the photos are any images from anywhere on the Internet > > that the user has chosen to link to. The Atom collection is protected, > > but not the photos. The token absolutely must not be sent when getting > the photos. > > > > > > > > > > > > A client app needs to know whether the service it is accessing is like > > A, B, or C. It needs to know for redirects, for links in HTTP headers, > > for links to images, for any other sort of link that is can derive from the > response. > > > > > > > > Some services might be completely walled gardens so the client can > > assume they are like A. > > > > Some services might explicitly state in their documentation: which > > links and redirects are always guaranteed to be other API calls (send > > the token); which will always be to other security contexts (don't > > send the token); and which might be either (don't send the token, see > > if you get a 401/403, guess, send the token). > > > > > > > > In general, the web is about following links. Clients need to know > > when following a link crosses a security boundary. Cookies provide > > this; Basic provides this; Digest provides this; OAuth needs this too. > > > > > > > > > > > > -- > > > > James Manger > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
