（oauth2）Gitee授权登录
代码地址
OAuth2 简介
OAuth 是一个开放的非常重要的认证标准/协议，该标准允许用户让第三方应用访问该用户在某一网站上存储的私密资源（如头像、照片、视频等），并且在这个过程中无须将用户名和密码提供给第三方应用。
通过令牌（token）可以实现这一功能，每一个令牌授权一个特定的网站在特定的时段内允许可特定的资源。
OAuth 让用户可以授权第三方网站灵活访问它们存储在另外一些资源服务器上的特定信息，而非所有内容。
对于用户而言，我们在互联网应用中最常见的 OAuth 应用就是各种第三方登录，例如QQ授权登录、微信授权登录、微博授权登录、GitHub 授权登录等。
例如用户想登录 Ruby China，传统方式是使用用户名密码但是这样并不安全，因为网站会存储你的用户名密码，这样可能会导致密码泄露。这种授权方式安全隐患很大，如果使用 OAuth 协议就能很好地解决这一问题。
注意: OAuth2 是OAuth 协议的下一版本，但不兼容 OAuth 1.0。
OAuth2 关注客户端开发者的简易性，同时为 Web 应用、桌面应用、移动设备、IoT 设备提供专门的认证流程。
OAuth2 授权总体流程
角色梳理: 第三方应用 <----> 存储用户私密信息应用 ----> 授权服务器 ----> 资源服务器
整体流程如下:
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。
从上图中我们可以看出六个步骤之中，B是关键，即用户怎样才能给客户端授权。同时会发现 OAuth2 中包含四种不同的角色：
- Client： 第三方应用。
- Resource Owner：资源所有者。
- Authorization Server ：授权服务器。
- Resource Server： 资源服务器。
四种授权模式
授权码模式
授权码模式（Authorization Code） 是功能最完整、流程最严密、最安全并且使用最广泛的一种OAuth2授权模式。同时也是最复杂的一种授权模式，它的特点就是通过客户端的后台服务器，与服务提供商的认证服务器进行互动。
其具体的授权流程如图所示:
- Third-party application：第三方应用程序，简称"客户端"（client）；
- Resource Owner：资源所有者，简称"用户"（user）；
- User Agent：用户代理，是指浏览器；
- Authorization Server：认证服务器，即服务端专门用来处理认证的服务器；
- Resource Server：资源服务器，即服务端存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
具体流程如下:
- （A）用户访问第三方应用，第三方应用通过浏览器导向认证服务器。
- （B）用户选择是否给予客户端授权。
- （C）假设用户给予授权，认证服务器将用户导向客户端事先指定的 "重定向URI"（redirection URI），同时附上一个授权码。#token
- （D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，
对用户不可见。 - （E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。
核心参数:
wx.com/oauth/autho…
简化模式
简化模式（implicit grant type） 不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。其具体的授权流程如图所示
具体步骤如下:
- （A）第三方应用将用户导向认证服务器。
- （B）用户决定是否给予客户端授权。
- （C）假设用户给予授权，认证服务器将用户导向客户端指定的 "重定向URI"，并在
URI的Hash部分包含了访问令牌。 - （D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
- （E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
- （F）浏览器执行上一步获得的脚本，提取出令牌。
- （G）浏览器将令牌发给客户端。
核心参数:
wx.com/oauth/autho…
密码模式
密码模式（Resource Owner Password Credentials Grant） 中，用户向客户端提供自己的用户名和密码。
客户端使用这些信息，向 "服务商提供商" 索要授权。
在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。
这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个相同公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。其具体的授权流程如图所示
具体步骤如下:
- （A）用户向客户端提供用户名和密码。
- （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
- （C）认证服务器确认无误后，向客户端提供访问令牌。
核心参数:
wx.com/token?grant…
客户端模式
客户端模式（Client Credentials Grant） 指客户端以自己的名义，而不是以用户的名义，向 "服务提供商" 进行认证。 严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求 "服务提供商" 提供服务，其实不存在授权问题。
具体步骤如下:
- （A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
- （B）认证服务器确认无误后，向客户端提供访问令牌。
OAuth2 标准接口
/oauth/authorize: 授权端点/oauth/token: 获取令牌端点- /oauth/confirm_access：用户确认授权提交端点
- /oauth/error：授权服务错误信息端点
- /oauth/check_token：用于资源服务访问的令牌解析端点
- /oauth/token_key：提供公有密匙的端点，如果使用JWT令牌的话
Gitee 授权登录（主要展示了 OAuth2 中客户端的工作模式。）
创建 OAuth 应用
- 找到第三方应用
- 创建 OAuth App并输入以下基本信息:
- 查看gitee授权之后的信息（说明授权完成）
gitee中能看到已授权信息
异常记录
Caused by: java.lang.IllegalStateException: Client id must not be empty.
原因：gitee写成github了
Caused by: java.lang.IllegalStateException: Unknown provider ID 'gitee'
原因：未配置provider。oauth-client官方只提供了github和google的登录,所以其他方式需要自己定义provider
[missing_user_info_uri] Missing required UserInfo Uri in UserInfoEndpoint for Client Registration: gitee
UserInfoEndpoint 中缺少客户端注册所需的 UserInfo Uri
解决：在配置文件中添加user-info-uri
引用：
- 编程不良人
- 基于Spring oauth2.0统一认证登录，返回自定义用户信息_oauth2.0 返回数据内容-CSDN博客
- SpringSecurity学习（八）OAuth2.0、授权服务器、资源服务器、JWT令牌的使用_springsecurityoauth2资源服务器-CSDN博客
- Spring Security OAUTH2 获取用户信息_token-info-uri-CSDN博客
- spring boot +spring security + oauth 2 实现 gitee授权登录 - 随意的马蒂洛克 - 博客园 (cnblogs.com)
- Gitee OAuth 文档 spring boot 2.x 中使用oauth2趟坑记录(一文横推oauth2) - 知乎 (zhihu.com)
