It depends, actually. There are many cases where you don't trust the redirect_uri, and you don't want to send the user to a redirect_uri that you, the server, don't trust. Otherwise you open yourself up to be an open redirector, possibly exposing your users to attacks from things like malware and phishing sites that the co-opt the redirect_uri to get people there.
-- Justin On May 6, 2013, at 8:17 AM, Ivan Martinez <[email protected]<mailto:[email protected]>> wrote: Thanks a lot, Justin. I suppose, then, that the error responses specified in 4.1.2.1 should be forwarded to the redirection URI, rather than being replied to the request. Iván El martes, 30 de abril de 2013 18:50:48 UTC+2, Justin Richer escribió: That's a correct reading. Usually what happens in most implementations is that you'll have an authorization page that presents the user with the choice to authorize the app, and that page will be protected by an end-user authentication (ie, it will require login). When the authorization page is served, the server should do some checks on things like if the client_id presented is valid, if the client has access to the scopes it's asking for, if the request_uri provided matches the ones registered, etc. In several implementations that I've seen (including the Java-based SECOAUTH that I've used extensively), this is actually split up into three responders: - something to catch the initial authorization request, check the client_id and related information, and make sure the user is logged in. This is forwarded to: - something to prompt the end-user to authorize the client. This usually is an HTML form and might have options for things like allowing and disallowing certain scopes. This form is submitted back to: - something to process the form results and create the authorization grant, which in turn creates (in this flow) the authorization code and redirects the user back to their client's redirect_uri. Don't know how best to arrange things in Erlang, but I'd recommend looking at implementations in other languages if you can. -- Justin On 04/30/2013 10:37 AM, Ivan Martinez wrote: Hello all, I'm a OAuth2 newbie trying to implement an authorization server in Erlang. I'm currently working on the "4.1 Authorization Code Grant" flow of the protocol, but I don't how to fit the resource owner's authorization steps into it. I understand the client first sends an authorization request as specified in 4.1.1, but now, how is the authorization form presented to the resource owner?. Should it be the response to the mentioned 4.1.1 request?. Thank you, Ivan -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<javascript:>. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
