[Openid-specs-ab] Additional issues with redirect
ve7jtb at ve7jtb.com
Sat May 19 12:49:07 UTC 2012
So to build a flow chart.
So if the client registers only one redirect URI do they need to send it in the request?
If they don't need to send it in the authz request, do they need to send it to the token endpoint?
My reading of OAuth is that that is not required in the single registered redirect case.
Are there any flows where Google supports unregistered redirects.
If we were to allow unregistered redirects that would make things interesting for 'code token' and 'code token id_token'.
We would need to make id_token nonce checking a MUST for those flows with unregistered redirect_uri, otherwise they are too easily intercepted and replayed to the client.
On 2012-05-19, at 1:34 AM, Breno de Medeiros wrote:
> On Fri, May 18, 2012 at 5:46 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> If there is an exact match of the redirect URI at the authz server is there a requirement for the client to send the redirect_uri to the token endpoint to match again, or is that only required if there was no redirect uri registered?
>> And that takes us back to the original question of should we allow unregistered redirect URI in any flow.
>> The answer was yes from some people to support query parameters.
>> It seems that matching all of the URI leads us to allow unregistered redirect_uri which is sort of the worst of both worlds as you become an open redirector as well.
>> More thoughts?
> Google authz server requires exact match and allows no query
> parameters. The OAuth2 protocol was designed to support this by adding
> a pre-defined state parameter.
> As for the redirect URI match in the token request -- I don't think it
> is only important _if_ the server allows for arbitrary query
> parameters to be added. So for servers that implement strict matching
> it's not important. However, for protocol compliance we currently
> enforce this.
>> On 2012-05-18, at 8:17 PM, Richer, Justin P. wrote:
>>> As I read things, I see it as an error as well. I can see the point in relaxing, since it would mean less to remember for both client and AS, but I think it's clearer if there's one code path, and only one path, to take if the client sends the redirect_uri to the authz endpoint.
>>> I feel like this needs flowcharts or something. Maybe I'll try to draw them up for the group sometime here.
>>> -- Justin
>>> From: John Bradley [ve7jtb at ve7jtb.com]
>>> Sent: Friday, May 18, 2012 5:41 PM
>>> To: Richer, Justin P.
>>> Cc: <openid-specs-ab at lists.openid.net>
>>> Subject: Re: [Openid-specs-ab] Additional issues with redirect
>>> What is your interpretation opt OAuth where:
>>> 1: the client registers multiple redirect_uri.
>>> 2: The client senda a redirect_uri in authz request with query paramaters.
>>> 3: The authz server matches the redirect URI with one of the registered ones up to the query string.
>>> 4: The client makes a request to the token endpoint without a redirect_uri
>>> Is this fine or an error.
>>> My reading of the OAuth Draft implies that this should return an error.
>>> Though from a security point of view the authz server matching the first time should be sufficient.
>>> This is needs to be clear for interop. If a client only registers one redirect_uri and simply sends a redirect_uri in the request to maintain some state in a query parameter, should it be forced to remember that parameter and sent it in the request to the token endpoint?
>>> John B.
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4937 bytes
Desc: not available
More information about the Openid-specs-ab