Hi Sergey, Yes, HTTP 400 is one way to handle a missing response_type with a "universal" authz endpoint.
Or, you could encode the error in the query string as well as the fragment, and redirect back to the client. 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 -- 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
