标签：STM32F103 uCOS 微信 server access client 授权 OAuth2.0 III
uCOS-III 应用开发指南—基于 STM32F103系列
嵌入式经典教材
【实例截图】
文件：590m.com/f/25127180-490253580-defdec（访问密码：551685）
以下内容无关：
-------------------------------------------分割线---------------------------------------------
没看之前以为OAuth2.0是登录认证授权的东西，自己的项目里应该是需要的。实际上OAuth是为了第三方应用访问我们资源用的，大多数开发者基本不会用到这个东西。对于自己应用的认证授权，还是基于拦截器的token，SpringSecurity即可。只有做平台级别，像微信，微博，github这种级别才会用到。而真到那个时候，再看也行，也通常不会是你来做。简而言之，非必须。
接下来，我将从几个方面了解和学习使用OAuth2.0。对不对就不管了，反正我也几乎不会用到。ps.有个项目用到了，所以才会有本文。
OAuth2.0介绍和功能
微信开放平台和github的OAuth2.0接入应用
自己写一个OAuth2.0服务
Springboot OAuth2.0集成
快速了解OAuth2.0
资源很多，看起来比较麻烦，可以直接看Authorization Code授权码流程，以微信登录为例子的介绍。
OAuth2.0是什么
官方介绍是： OAuth 2.0授权框架允许第三方应用程序通过协调资源所有者和HTTP服务之间的审批交互，或允许第三方应用程序自己获得访问权限，从而获得对HTTP服务的有限访问。也就是授权别人(client)访问我们的资源。
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.
别人(client)是什么？
登录石墨文档可以输入账号密码登录，也可以选择微信登录，微信扫码确认后，就登录了石墨文档。石墨文档通过微信认证的方式实现了自身的认证登录。这个石墨文档就是client的角色（Role）。
什么时候需要让别人(client)访问我们的资源？
最常见的是微信授权登录，对client来说，是用户授权client拿到用户在微信上的信息，比如性别，唯一id。
我们怎么才能做到授权给别人访问我们的资源？
我们自己怎么获取自己的资源？我们登录后就可以获取到自己的账号信息等资源了。那么怎么给到别人？直接把我们的账号密码给第三者太不安全了。一个是自己的账号密码存在泄露的风险，一个是自己的账号权限太大，万一被别人删除了或者看到了不该看到的东西怎么办。在使用阿里云的时候，我们可以给自己的账号开子账号，给子账号一些权限访问哪些服务(授权太复杂了)，这样我们就可以达到最初的目的了： 让别人安全的访问我们的资源。
OAuth通过引入授权层并将client的角色与资源所有者的角色分离, 并且给client单独的凭证(access_token)，client通过access_token获取有限的资源。
OAuth2.0定义的角色
resource owner
资源的拥有者，通常就是用户，比如登录的用户。
resource server
资源服务，提供资源的服务。需要access_token才允许被调用。比如微信api，通过access_token调用它可以获取到用户的性别等信息。
client
客户端，第三方客户端，被授权访问的应用。比如石墨文档通过微信登录的时候，石墨文档就是client角色，它要用户授权获取用户微信的信息。
authorization server
资源认证授权服务。用户登录到本服务后，可以选择授权给第三方。比如微信登录，微信认证服务就是authorization server的角色。可以颁发给client code，可以通过code换取access token. 可以通过access_token认证用户。
乍一看可能有点迷乱。站在登录用户的角度，简单的分为3个阵营: 用户本身(resource owner), 用户要登录的应用(client), 用户的资源(resource server and authrization server). authorization server和resource server是一体的，一家的，比如都是微信的。这样清晰一些。只是对于微信内部，个人信息，朋友圈，公众号，小程序啥的，资源挺多，相当于多个resource server, 内部就分成了authorization server和多个resource server.
搞清楚这里面的角色后，再来看协议的流程。
OAuth2.0的协议流程
整体抽象协议流程如下。
A: client找用户(resource owner)请求授权，说你得让我获取你的微信昵称. 然后用户就看到微信授权页面(authorization server)显示是否允许client获取昵称。
B: 用户点确认，微信就会给client一个临时授权code。
C: client拿着上一步得到的授权code去找authorization server换一个access_token.
D: authorization server认证了client的参数，确认后，给client返回access_token.
E: client拿access_token去获取信息，比如获取用户昵称，头像。
F: client如愿以偿。
直接看上面的图，看到B和C都特么叫Authorization Grant, 授权发放。一会儿用户给client发放，一会儿client又找authorization发放，这是要哪样。我当年就是看了无数次这个图没看懂。接着，一般的文章又会介绍OAuth2.0的4种授权方式，结合上图的授权，就会非常容易混淆，看不懂了。
标签：STM32F103,uCOS,微信,server,access,client,授权,OAuth2.0,III 来源： https://blog.csdn.net/weixin_43322764/article/details/115753062
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。