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 <sberyoz...@gmail.com> 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 >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
