Well, that makes sense for resource owner authorize to AS, then AS authorize to client. But it looks awkward for me to return the AS's authorization code to AS itself for access token. And in the current procedure of "resource owner authorize to AS", username and password are needed, which has risk of leaking password, further more passwords are not easy to be chosen strong enough.
Current cryptographic technology has provided practical methods to authorize by generating authorization statement locally without transporting password、secret key on line. why don't we use them? "the role of the signature you mentioned is like that of the username and corresponding password“ --Not exactly, the role is authentication and authorization at the same time; while the role of user name, password is only authentication, because authorization need user's interaction, such as a pressing. Guangqing Deng <[email protected]> 2012-09-04 09:53 收件人 [email protected] 抄送 [email protected] 主题 Re: Re: [OAUTH-WG] a question about authorization Maybe you can think in another way, the AS first obtain the authorization from the resource owner and then issue the authorization code to the client. There are many ways where the resource server give the authorization to the AS, for instance, the resource server sending the username and corresponding password to AS. In my opinion, the role of the signature you mentioned is like that of the username and corresponding password; what you said maybe is applicable but now is beyond the scope of current OAUTH. 2012/9/4 <[email protected]> Not exactly authorization code in authorization code flow. But something like it, say a signature on a delegation statement by user, user send it to the client, client exchange the signature for an access token. The AS can verify the signature's validity. The rationale in my question is that: the resource is of the resource owner, so it is the right and it is natural to let resource owner authorize the access to its resource, the role of AS in current Oauth's authorization code flow is just an authentication provider and should not decide the authorization. Guangqing Deng <[email protected]> 2012-09-03 17:33 收件人 [email protected] 抄送 [email protected] 主题 Re: [OAUTH-WG] a question about authorization besides, the user has no authorization code; the authorization server does have. 2012/9/3 Guangqing Deng <[email protected]> Why let the user send an authorization code to the client? Let client request an access token from authentication server using that authorization code? If so, authentication server can’t determine whether the authorization code is valid or not and will not issue an access token. 2012/9/3 <[email protected]> Hi,all I have always been unclear of one thing, why must let authorization server generate and issue authorization code to a client? Could not just let the user authorize the client directly by sending the client something like authorization code? Regards~~~ -Sujing Zhou _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth -- Guangqing Deng -- Guangqing Deng -- Guangqing Deng
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
