Re: [OAUTH-WG] Missing response_type with implicit and code flows on the same path

[John Bradley <[e-mail]>]

This trick works for the response types that use the GET POST and fragment encoded response modes. 

In the future if we do a Java Script response mode as is being proposed that might not always be the case.

Just a heads up.

Regards
John B.
> On Feb 10, 2016, at 7:09 AM, Sergey Beryozkin <[e-mail]> wrote:
> 
> Hi
> 
> I got it, thanks for clarifying the idea :-)
> 
> Thanks, Sergey
> On 10/02/16 07:59, Vladimir Dzhuvinov wrote:
>> 
>> 
>> On 09/02/16 18:21, Sergey Beryozkin wrote:
>>> Hi Vladimir
>>> 
>>> Thanks for the response,
>>> On 09/02/16 16:09, Vladimir Dzhuvinov wrote:
>>>> Hi Sergey,
>>>> 
>>>> Yes, HTTP 400 is one way to handle a missing response_type with a
>>>> "universal" authz endpoint.
>>>> 
>>> Indeed, looks like it makes sense
>>>> Or, you could encode the error in the query string as well as the
>>>> fragment, and redirect back to the client.
>>>> 
>>> I'm not sure if that can be done in a 'universal' endpoint case
>>> because it is not known if a client is running in the implicit context
>>> or code flow context. Though I guess it a client is restricted at the
>>> registration time to run only in the code or implicit flows then it
>>> will provide a hint...
>> 
>> If you set both the query and the fragment you'll take care of both flows :)
>>> 
>>> Cheers, Sergey
>>> 
>>>> Vladimir
>>>> 
>>>> 
>>>> On 09/02/16 16:39, Sergey Beryozkin wrote:
>>>>> Hi
>>>>> 
>>>>> OAuth2 spec recommends how to deal with a missing response_type, set
>>>>> an error as a query or fragment parameter, depending on whether it is
>>>>> the authorization code or implicit flow and redirect.
>>>>> 
>>>>> This implies that authorization code and implicit handlers listen on
>>>>> different paths, for example,
>>>>> 
>>>>> code: /code
>>>>> implicit: /implicit
>>>>> 
>>>>> so if a response type is missing the handler will know how to set the
>>>>> error on the redirect uri, as a query or a fragment.....
>>>>> 
>>>>> However, I'd like to have a single handler, example (from the OIDC
>>>>> core):
>>>>> 
>>>>> "https://server.example.com/authorize"
>>>>> 
>>>>> which will support both the code and implicit flows.
>>>>> 
>>>>> Here, 'response_type' is an obvious hint on what kind of flow is in
>>>>> process, however, if it is missing, how will a server know how to
>>>>> report a missing response_type error if it uses a shared "/authorize"
>>>>> path.
>>>>> 
>>>>> I think in such cases reporting 400 is reasonable. Do you agree ?
>>>>> 
>>>>> Thanks, Sergey
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth