Oauth2.0如何理解？

1、 Oauth2.0 解决了一个什么样的问题？

在此之前，我们在登陆每个应用时，采用账户和密码的模式。大家六亲不认，只认密码。同样，用户的应用与应用之间，也往往是这样的，如果应用A你要访问我应用B，那你必须要有客户在我应用B中的账户和密码。

这个优点是，简单，粗暴。缺点是，应用B的客户隐私都泄露了，谁都担心；另外，互相要记这么多账户和密码，特别是密码，谁受得了。特别是老同志。

有没有一个通用的应用（类似于QQ，微信，github），可以用来登陆其它的应用(比如csdn,知乎,163邮箱等)？

Oauth2.0就是解决这个问题的。

2、模式与区别

我们以QQ账户登陆csdn来举例：

在Oauth2.0模式下，【授权方和资源方】

QQ应用账户（授权方）去登陆csdn（第三方），此时是csdn访问QQ应用【QQ是资源方，不要搞反了】，访问QQ的用户的信息，以及其它授权的信息范围；在原来的模式下，需要QQ应用的账户和密码来验证；此时QQ不需要给密码，而是发token，这样，csdn可以用QQ方发的token也可以访问QQ.

相当于，你去银行取钱，你出示国家发的身份证，就可以；

而原来的模式是，csdn请你登陆者出示你在csdn注册的账户和密码，其它的什么身不身份证的，不管。

具体的模式是：

在上面，用几个角色：

比如资源所有方（resource owner）：用户
第三方应用：client Application ；在这里指的是csdn
资源服务器：resource server ; 指的是QQ
认证服务器：authorization server

在现实中，资源服务器与认证服务器往往为一体。比如QQ 。账户服务器（也就是资源服务器）和认证服务器往往就都由QQ方安排。

容易混同：

需要注明的是：当QQ去登陆CSDN时，是CSDN去访问和索要（get\post\put等）QQ的数据和信息，不是QQ去访问CSDN的信息。这个和直觉好象不符。这主要与展示产生的错觉有关。

总结一下：

授权服务器看到用户的授权发code；
授权服务器经验证程序后发token；
资源服务器负责给持有token的访问者，访问它的账户信息，以及其它授权信息(scope)；

3、Oauth2.0是如何工作？

Oauth2.0有四种模式，本文以授权码模式来介绍。

上一张图：【这个模式相对简化】

资料来源：https://zhuanlan.zhihu.com/p/46573571

从QQ账户登陆doubian的过程，比较清楚地介绍了这么几个流程：

用户登陆QQ->
QQ认证中心发出授权码code->
用户把获得的code给doubian ->
doubian把code给QQ认证中心->
QQ认证中心把token给doubian ->
doubian 带着token就可以访问QQ了【用户信息及其它信息】

4、为什么要有code呢？

code本身就临时的，比如，很多应用设置10分钟过期。即使code被人抢走，后用login时还是会产生code，会把前面的产生的token覆盖。

5、需要什么验证程序才发token？–签名验证算法

这个涉及到移动应用开发中AppID、AppKey、AppSecret。
具体参见：https://www.cn-shenliang.com/newsinfo/360153.html

其中， AppID：应用的唯一标识，“应用的身份证” 【这个我认为应是QQ认证这个应用的唯一编号，应是QQ方发的，待确认】
AppKey：公匙（相当于账号）【这个是应是开发人员通过算法生成的，也可以通过特定平台比如微信、QQ等平台的工具生成，这个是给QQ方解签用的】
AppSecret：私匙（相当于密码，与AppKey是一对的，类似RSA的一对key）【这个是开发人员签名用的，不能暴露给其它人】

我理解： doubian
用AppSecret即私匙对相关的信息（或其摘要）进行签名，同时发布Appkey公匙，让QQ 资源服务器去解签，如果成功，证明的确是由doubian发来。解签后，才发出token.
这里用到了签名的算法。

6、为什么Oauth2.0能起到安全认证的作用？

待补充

7、https起到什么作用？

防止token以明文的方式传输。正常的话，认证中心的token会以加密的方式。此时，支持https就是必要的。
如果全部以https传输的话，理论上code也可以不用（待确认）？

8、为什么需要url重定向？
因为h5或页面的跳转，不会自动生成，比如

当用户点击按钮同意授权后，授权服务器将生成一个用户凭证（code），此时授权服务器如何将用户凭证（code）传递给第三方应用呢？此时，就需要有重定向机制，即跳转环节。

9、token有效期多长？

正常情况下有access_token，expire_date,refresh_token三个字段。如果到期了，access_token就会失效，需要重新更新。
比如，我们在QQ上一个应用时，过了一段时间，就会要我们重新登陆。这个机制就被用上了。

参考资料：
1、http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
2、https://www.chrisyue.com/security-issue-about-oauth-2-0-you-should-know.html
3、https://zhuanlan.zhihu.com/p/46573571
4、https://zhuanlan.zhihu.com/p/20913727

其中，参考文献3的流程总结如下：

第1步. 用户授权用户身份确认后会进入下面这个页面，该页面由授权服务器提供，授权服务器会告诉用户该第三方在授权服务器中提交的相关信息（如果需要实现第三方登录功能，第三方应用需要向Github、微博等应用中提交应用的相关信息，不同服务可能会需要审核等不同的步骤），以及授权后第三方应用能够获取哪些资源。在Github中，最基础的认证可以访问用户的公共信息。如果用户同意授权，需要主动的点击【Authorize application】按钮。

第2步. 返回用户凭证（code）当用户点击按钮同意授权后，授权服务器将生成一个用户凭证（code），此时授权服务器如何将用户凭证（code）传递给第三方应用呢？当我们向授权服务器提交应用信息时，通常需要填写一个redirect_uri，当我们引导用户进入授权页面时，也会附带一个redirect_uri的信息（如Sign in to GitHub · GitHub），当授权服务器验证两个URL一致时，会通知浏览器跳转到redirect_uri，同时，在redirect_uri后附加用户凭证（code）的相关信息，此时，浏览器返回第三方应用同时携带用户凭证（code）的相关信息。授权后访问的redirect_uri如下：http://tianmaying.com/oauth/github/callback?code=9e3efa6cea739f9aaab2&state=XXX
这样，第二步返回用户凭证（code）就完成了。

授权服务器授权从这一步开始，OAuth2 的授权将有两个重大变化的发生：用户主动行为结束，用户理论上可以不需要再做任何主动的操作，作为第三方应用的我们可以在后台拿到资源服务器上的资源而对用户是不可见的，当用户的浏览器跳到下一个页面时，整个OAuth2的流程已经结束浏览器端行为结束，从OAuth2 的基本流程可以看出，接下来的流程已经不需要和用户进行交互，接下来的行为都在第三方应用与授权服务器、资源服务器之间的交互。我们知道浏览器端的行为实际上是不安全的，甚至安全凭证的传递都是通过URL直接传递的。但是由于用户凭证（code）不是那么敏感，其他攻击者拿到用户凭证（code）后依然无法获取到相应的用户资源，所以之前的行为是允许的。接下来我们看看服务器如何交互来安全的获得授权服务器授权。

第3步. 请求授权服务器授权要拿到授权服务器的授权，需要以下几个信息：client_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用client_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用code 第一步中返回的用户凭证redirect_uri 第一步生成用户凭证后跳转到第二步时的地址state 由第三方应用给出的随机码
我们看到，上述信息还涉及到第三方应用的安全凭证（client_secret），因此要求OAuth要求该请求必须时POST请求，同时，还必须时HTTPS服务，以此保证获取到的验证凭证（Access Token）的安全性。

第4步. 拿到验证凭证（Access Token）当授权服务器拿到第3步中的所有信息，验证通过后，会将Access Token返回给第三方应用。
访问资源

第5步. 请求访问用户资源拿到验证凭证（Access Token）后，剩下的事情就很简单了，资源服务器会提供一系列关于用户资源的API，拿验证凭证（Access Token）访问相应的API即可，例如，在GIthub中，如果你想拿到用户信息，可以访问以下API：GET https://api.github.com/user?access_token=…
注意，此时的访问不是通过浏览器进行的，而是服务器直接发送HTTP请求，因此其安全性是可以保证的。

第6步. 返回资源如果验证凭证（Access Token）是正确的，此时资源服务器就会返回资源信息，此时整个OAuth流程就结束了。

Oauth2.0如何理解？相关推荐

OAuth2.0的理解基础
OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版. 1. 应用场景为了理解OAuth的适用场合,让我举一个假设的例子. 有一个&quo ...
新浪微博OAuth2.0认证理解
学习网络和程序也有一段时间了,但是真枪实弹的干还是没有好好的重试过,导致应聘软件实习生一次次被拒. 看到网上有很多开发开发平台,公司不让我练手,我自己拿自己练手总可以了吧. 大型网站(新浪微博,淘宝, ...
深入理解OAuth2.0协议
1. 引言如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店 ...
sso和oauth2.0的简单了解学习
sso,单点登录,single sign on 缩写.sso多用于多个应用之间的切换,例如百度论坛.百度知道.百度云.百度文库等,在其中一个系统中登录,(登录有效期内)切换到另一个系统的时候,不必再次 ...
最近在学OAuth2.0协议，给大家分享一下
1. 引言如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店 ...
使用Oauth2.0实现微博授权登录
本文章参考资料: http://blog.csdn.net/highboys/article/details/52139268 http://blog.csdn.net/yypsober/articl ...
SSO单点登录和OAuth2.0的区别和理解
一.概述 SSO是Single Sign On的缩写,OAuth是Open Authority的缩写,这两者都是使用令牌的方式来代替用户密码访问应用.流程上来说他们非常相似,但概念上又十分不同.SSO ...
Spring Security并没有那么难嗷简单理解OAuth2.0
文章目录 1. 基本概念 1.1 什么是认证 1.2 什么是会话 1.3 什么是授权 1.4 授权的数据模型 1.5 RBAC 1.5.1 基于角色的访问控制 1.5.2 基于资源的访问控制 2. 基 ...
android sina oauth2.0 code认证,Android通过第三方登录理解oauth2.0机制
1. OAuth2.0介绍说到第三方登录,离不开oauth2.0,oauth2.0是"用户认证和授权的标准",是从oauth1.0基础上发展来的.下图是oauth2.0六个过程分 ...
大话微服务：Spring Cloud gateway+OAuth2 实现单点登录和权限控制（二） OAuth2.0 四种模式的通俗理解
一. 概述 OAuth2.0的规范要求,就是客户端(即通常是各个应用程序)要访问资源所有者时,经过资源所有者同意后,由Oauth向这个客户端颁发令牌.为了满足互联网不同的场景 ,规定了四种获得令牌的流 ...

Oauth2.0如何理解？

Oauth2.0如何理解？相关推荐

最新文章

热门文章