浅谈安全协议之OAuth.ppt
浅谈OAuth安全协议,求知+分享,39健康网 技术部,目录,什么是OAuth,什么是OAuth|三种角色,为海量用户提供服务的平台,新浪微博,腾讯微博,GoogleService,Tiwtter,大量的用户群,什么是OAuth|三种角色,消费方（官方）,为Provider提供APP的第三方开发者,Weico,什么是OAuth|三种角色,Provider 和 Consumer 的使用者,什么是OAuth|三种角色,举一个通俗易懂的例子,Oauth的认证流程|虚拟的取钱案例,Oauth的认证流程|虚拟的取钱案例,Oauth的认证流程|官方的流程,Oauth的认证流程|官方的流程,Oauth的认证流程|官方的流程,Oauth的认证流程|官方的流程,最清晰明了的流程图,Oauth的认证流程|参数简介,Consumer,CONSUMER_KEY,CONSUMER_SECRET,OAUTH_CALLBACK_URL,Consumer在Provider注册。,用户授权后的返回地址,OAUTH_NONCE,OAUTH_SIGNATURE_METHOD,OAUTH_VERSION,OAUTH_TIMESTAMP,随机字符串，须保证每次都不同,签名base string 的方法，目前支持HMAC-SHA1,时间戳,Oauth协议版本,Oauth的认证流程|参数简介,Provider,REQUEST_URL,ACCESS_URL,AUTHORIZE_URL,OAUTH_TOKEN,OAUTH_TOKEN_SECRET,向应用服务商（新浪、搜狐等微博）请求request_token。,得到request_token后重定向用户到服务商的授权页面。,用户选择授权后，用request_token向服务商请求换取access_token。,OAUTH_ACCESS_TOKEN,OAUTH_TOKEN_SECRET,Oauth的认证流程|第零步 注册Consumer,Consumer,Oauth Provider,1.Consumer向Provider注册，提交申请。,2.Provider生成Key和Secret返回给Consumer。,Oauth的认证流程|第一步 请求未授权的request_token,请求地址Url：,oauth_consumer_key,oauth_signature_method,oauth_signature,oauth_timestamp,oauth_callback,oauth_version,请求地址参数：,request_token,Oauth的认证流程|第一步 请求未授权的request_token,oauth_signature（请求签名）,所有TOKEN请求和受保护的资源请求必须被签名，Provider会根据签名来判断请求的合法性。签名算法使用Signature Base String和密钥（Secret）生成签名，参数oauth_signature用于指定签名。,Oauth的认证流程|第一步 请求未授权的request_token,请求后返回参数：,oauth_token,oauth_token_secret,未授权的Token和Secret,Oauth的认证流程|第二步 请求用户授权request_token,请求地址Url：,请求地址参数：,authorize,oauth_token（未授权的Request Token）,说明：此页面中会要求用户登陆，然后选择同意或者拒绝对应用授权。授权成功后，Provider会重定向到oauth_callback所指定的URL。（返回授权之后的Token值，与未授权Token值相同。）。,Oauth的认证流程|第三步 使用授权后的Request Token换取Access Token,请求地址Url：,请求地址参数：,oauth_consumer_key,oauth_signature_method,oauth_signature,oauth_timestamp,oauth_callback,oauth_version,oauth_token,Oauth的认证流程|第三步 使用授权后的Request Token换取Access Token,请求后返回参数：,oauth_token,oauth_token_secret,真正授权的Token和Secret,Oauth的认证流程,看似简单的流程,搭建自有的Oauth服务,自有Aouth服务的好处1.各个系统暴露的接口不再需要各自化的验证2.验证的业务流程全部在一个服务处操作3.接入方便，统一管理,搭建自有的Oauth服务,开源的OAuth,1.多语言支持,2.Provider端,3.Consumer端,服务端,搭建自有的Oauth服务,1.java语言支持,2.复杂的操作简单化,客户端,开源的Signpost,3.插件化,Big idea,39的Oauth,39OAuth_Provider,System1,System2,sys1和sys2都有在Oauth端注册过,1.S1请求request_token,2.Provider返回request_token,3.S1验证用户信息,4.Provider给S1授权access_token,5.Provider告知S2，S1在Provider端验证通过,6.S1去请求S2的接口,7.S2返回结果,39的Oauth|Provider,39的Oauth|Consumer,39的Oauth,在此输入标题,谢谢您的耐心阅读！,
