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 >> > > -- Vladimir Dzhuvinov :: vladi...@connect2id.com
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
