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

[Vladimir Dzhuvinov <[e-mail]>]

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
>>
>
>

-- 
Vladimir Dzhuvinov :: [e-mail]