This is coming from recent experience building a full web service and multiple clients using OAuth 2.0. I am going to make these changes to my own implementation and would like to raise the questions here and discuss possible changes.
A few questions: 1. Why not require the registration of a redirection URI for implicit grant requests, removing the redirect_uri parameter completely from the request (the client can still use the state parameter)? 2. What is the value of the client_id when a redirection URI is not pre-registered? The client identity cannot be verified without other means for the purpose of informing the user who is asking for access, no refresh token is issued, and the redirect_uri parameter contains the only useful information for both the flow and identifying the client (to the extent it can be trusted not to be an open redirector). 3. Are there real use cases for performing redirection URI matching against a pre-registered value, where partial (i.e. not string) comparison is needed? Why can't this be solved by simply using any URI variations into the state parameter? Changes I would like to see: The implicit grant should be split into 2 flavors (can be given different grant type name or just using normative language to define the restrictions), one with client_id and state, and one with redirect_uri only. Registered client: the client request token response type by including its client identifier and optional state parameter. No redirect_uri is allowed. The authorization server will be able to inform the user about the client identity, where the token will be sent (the domain of the registered URI, if the server can verify if the endpoint is not an open redirector), and prevent others from hijacking the client identifier for their own application. The exception is when using custom URI schemes which other applications can hijack on the local operating system (but that's the least of our concern if a native application is doing bad things). Unregistered client: the client request token response type by including a redirection URI (no client_id or state). The authorization server may require registration of the redirection URI for the purpose of accepting terms of service, but not issue an client identifier which is useless without a registered redirection URI. This way, the operator of example.com can go to the authorization server and ask to enable issuing tokens to requests with callbacks at example.com, in case the authorization server requires some legal contracts before sharing data. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
