一、OAuth协议简介
OAuth授权在各社交网站中广泛使用,该协议使用户不需要直接向第三方应用提供用户名及密码,并且使一个账户在多个网站中使用成为可能,OAuth协议的细节描述可参考其官方网站:http://oauth.net
目前OAuth 1.0已经出了final version,即RFC 5849,OAuth 2.0也已在起草中。
这篇文章中,我想用比较通俗的语言来解释OAuth协议。
OAuth协议中包含了三个角色:
Service Provdier,即服务提供者,如新浪微博;
User,即普通用户,如新浪微博用户;
Consumer,即第三方应用,如本人开发的应用。
现有如下场景:User想利用Consumer来更新自己在Service Provider中的状态,但此时Service Provider并不信任Consumer,且User也不想把帐号和密码告诉Consumer,于是三者之间需要建立起信任关系。
Consumer首先要向Service Provider申请一对Consumer_Key和Consumer_Secret,以此取得Service Provider的信任。因为User是信任Service Provider的,所以User与Consumer间的信任关系需要借助Service Provider来建立。
Consumer用自己的Consumer_Key和Consumer_Secret向Service Provider请求到一对Request_Token和Request_Token_Secret,而后Consumer拿上这对RequestToken,领着User去见Service Provider。Service Provider见到自己发的RequestToken,便确认Consumer是值得信任的,于是把头转向User。如果Service Provider不记得User了,只要User向Service Provider提供用户名和密码,就能建立起信任关系。然后Service Provider对User说:“我很信任这个Consumer,你是不是也要信任他?”,若User确认,则Service Provider允许Consumer把User带回去,并发给Consumer一个Verifier.
回来以后,Consumer拿着RequestToken和Verifier又单独去找Service Provider,取回来一对Access_Token和Access_Token_Secret,并长期保存。
至此,三方信任关系就建立起来了,Consumer每次在Service Provider中更新User的状态时,只需要提供这对AccessToken,Service Provider便能确定此Consumer能代替User进行相应的操作。
在使用相关OAuth库进行开发时,所需要的关键字在以上场景中都有体现,包括:
Consumer_Key, Consumer_Secret, Request_Token, Request_Token_Secret, Verifier, Access_Token, Access_Token_Secret
OAuth授权在各社交网站中广泛使用,该协议使用户不需要直接向第三方应用提供用户名及密码,并且使一个账户在多个网站中使用成为可能,OAuth协议的细节描述可参考其官方网站:http://oauth.net
目前OAuth 1.0已经出了final version,即RFC 5849,OAuth 2.0也已在起草中。
这篇文章中,我想用比较通俗的语言来解释OAuth协议。
OAuth协议中包含了三个角色:
Service Provdier,即服务提供者,如新浪微博;
User,即普通用户,如新浪微博用户;
Consumer,即第三方应用,如本人开发的应用。
现有如下场景:User想利用Consumer来更新自己在Service Provider中的状态,但此时Service Provider并不信任Consumer,且User也不想把帐号和密码告诉Consumer,于是三者之间需要建立起信任关系。
Consumer首先要向Service Provider申请一对Consumer_Key和Consumer_Secret,以此取得Service Provider的信任。因为User是信任Service Provider的,所以User与Consumer间的信任关系需要借助Service Provider来建立。
Consumer用自己的Consumer_Key和Consumer_Secret向Service Provider请求到一对Request_Token和Request_Token_Secret,而后Consumer拿上这对RequestToken,领着User去见Service Provider。Service Provider见到自己发的RequestToken,便确认Consumer是值得信任的,于是把头转向User。如果Service Provider不记得User了,只要User向Service Provider提供用户名和密码,就能建立起信任关系。然后Service Provider对User说:“我很信任这个Consumer,你是不是也要信任他?”,若User确认,则Service Provider允许Consumer把User带回去,并发给Consumer一个Verifier.
回来以后,Consumer拿着RequestToken和Verifier又单独去找Service Provider,取回来一对Access_Token和Access_Token_Secret,并长期保存。
至此,三方信任关系就建立起来了,Consumer每次在Service Provider中更新User的状态时,只需要提供这对AccessToken,Service Provider便能确定此Consumer能代替User进行相应的操作。
在使用相关OAuth库进行开发时,所需要的关键字在以上场景中都有体现,包括:
Consumer_Key, Consumer_Secret, Request_Token, Request_Token_Secret, Verifier, Access_Token, Access_Token_Secret