Am 22.04.2010 02:23, schrieb Evan Gilbert:
At one point we had tokens in query string for the User-Agent
flow, but there were concerns about the security side. Query
parameters are much more likely to leak in logs and in referrers.
It's not a lot of work to support this functionality with the
existing User-Agent flow using a boilerplate response page. Page
would:
1. Grab fragment
2. Make XMLHttpRequest with access token & refresh token to
server, or POST a form
3. Redirect to destination page.
Would this work?
I think this would work but is IMHO somehow cumbersome and
requires two requests to the service.
I agree it's cumbersome. Hopefully the security folks can respond with
the pros/cons of tokens in the query parameters.
I dicussed security considerations in my proposal. Depending on the risk
assessment of the application/deployment, one will need to sign the
request or encrypt the response.
Alternatively, the authorization server could directly respond
with a HTML page containing a HTML form element with all response
data. This form could automatically be submited to the service
using JavaScript. This would be similar to OpenIds "HTML FORM
Redirection".
This is a good idea. Might make sense to support as a best practice -
the form can be static and it's fairly easy for any client to host it.
We recently had a similar discussion on the Native Application flow on
the OAuth WG thread - decided that we could implement the Native Flow
as the Web Server flow + a simple HTML web page. And the web page
wouldn't be directly part of the spec, but a separately documented
best practice.
(note - I don't have strong opinions on this - mostly discussing options)
I don't know whether the flow can really be implemented w/o standard
support.
1) The server has to decide when to respond with conventional redirect
and when with HTML FORM Redirection. This could probably be setup on a
per client base.
2) The client may not perform the second call in order to retrieve the
tokens. Instead it shall use the response parameters. I don't expect
libraries to support this behavior as long as the standard does not
specifies it.
regards,
Torsten.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
