SpringAuthorizationServer-基本概念
OAuth2是一个对外开放的第三方授权协议，允许用户不提供第三方应用的账号信息的前提下以授权的方式获得第三方应用资源的访问令牌，从而能够访问第三方资源。
Spring Authorization Server
认证与授权
认证（Authentication）：用户认证，就是验证此用户的身份。解决的是‘我是谁’的问题。就是从用户请求信息中获取用户信息的过程，认证是一个过程。
当你在登录时，输入用户名密码，系统判断你的用户名与密码是否在已有的用户内并给出结果反馈，这个过程就是用户认证。 用户名+密码登录，手机、邮箱验证码，第三方登录等都属于用户认证的一种。
授权（Authorization）：用户授权，就是授予用户权限，能够进行后续的某些访问和操作。解决的是“我能干那些事”的问题。就是从获取到用户信息到授予用户权限的过程。
每天乘电梯刷卡，刷卡的过程就是授权，授予了我们访问某某层的权限。就相当于是某个人或者某个机构赋予某人干某事的权限的过程。
认证角色draft-ietf-oauth-v2-1-07
Resource Owner：资源拥有者；能够授予对受保护资源的访问权限的实体，通常指的是终端用户。
Client：客户端；代表资源所有者发出受保护资源请求并获得其授权的应用程序。
Authorization Server：认证服务器；服务器在成功对资源所有者进行身份验证并获得授权后向客户端发出访问令牌。
Resource Server：资源服务器；托管受保护资源的服务器，能够使用访问令牌接受和响应受保护的资源请求。
授权模式
oauth2.1移除了隐式授权模式(Implicit grant)和密码模式(Resource Owner Password Credentials Grant)。
oauth2.0区别：draft-ietf-oauth-v2-1-00
传统的用户名和密码登录方式会出现安全问题，相当于你在不受信任的网站登录时候，使用了受信任的网站的信息。但Oauth2更偏向于授权，实际上如果你不勾选授权，他是无法访问到你的个人信息（头像那些），这也是为什么很多时候授权勾选个人信息的框是灰色，默认选中的原因。密码模式移除：draft-ietf-oauth-security-topics-24
授权模式
授权码模式：draft-ietf-oauth-v2-1-07
授权码模式（Authorization Code Grant）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动；
授权码扩展流程PKCE：RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients (ietf.org)
使用授权码授予的OAuth 2.0公共客户端是易受授权码拦截攻击。该流程可以减轻攻击，通过使用代码交换证明密钥来抵御威胁。客户端生成code_verifier和code_challenge跟认证服务器进行交互，以生成的随机认证码进行身份认证。
客户端模式：draft-ietf-oauth-v2-1-07
客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题；
设备授权码模式：RFC 8628 - OAuth 2.0 Device Authorization Grant (ietf.org)
设备授权码模式（Device Authorization Grant）主要会出现在凭证式授权类型中，为设备代码，设备流中无浏览器或输入受限的设备提供的一种认证方式，设备会让用户在另一台设备上的浏览器中访问一个网页，以进行登录。 用户登录后，设备可以获取所需的访问令牌和刷新令牌；
刷新access token：刷新令牌在获取access token时会同步获取刷新令牌(Refresh token)，如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌(Refresh token)"申请一个新的访问令牌。
Token
令牌生成器：框架提供了令牌生成器（OAuth2TokenGenerator），负责从提供的OAuth2TokenContext中根据TokenType类型生成对应的OAuth2Token，tokenGenerator很灵活，它可以支持access_token和refresh_token的任何自定义令牌格式。
JWT RFC 7519 - JSON Web Token (JWT) (ietf.org)
JWS RFC 7515 - JSON Web Signature (JWS) (ietf.org)
客户端认证方式
client_secret_basic
客户端将clientId 和 clientSecret 通过 ‘:’ 号拼接，并使用 Base64 进行编码得到一个字符串。将此编码字符串放到请求头(Authorization)去发送请求。授权服务器通过获取请求头中的clientId和clientSecret对客户端进行认证。
client_secret_post
客户端将 clientId 和 clientSecret 放到请求体(表单)去发送请求。授权服务器获取请求参数中的clientId和clientSecret对客户端进行认证。
client_secret_jwt
client_secret_jwt方式就是利用 JWT 进行认证。请求方和授权服务器，两者都知道客户端的 client_secret，通过相同的 HMAC 算法（对称签名算法）去加签和验签 JWT ，可以达到客户端认证的目的。请求方通过HMAC算法，以 client_secret 作为密钥，将客户端信息加签生成 JWT；授权服务器使用相同的HMAC算法和client_secret，对请求方的 JWT 进行验签以认证客户端。
private_key_jwt
private_key_jwt 方式就是利用 JWT 进行认证；请求方拥有自己的公私钥（密钥对），使用私钥对 JWT 加签，并将公钥暴露给授权服务器；授权服务器通过请求方的公钥验证 JWT，也能达到客户端认证的目的。请求方维护了一对公私钥，通过 RSA算法，使用私钥将客户端信息加签生成 JWT；另外还通过接口暴露公钥给授权服务器；授权服务器使用请求方的公钥对请求方的 JWT进行验签以认证客户端。
none (public clients)
当客户端是公共客户端时认证服务器不会对客户端进行验证，PKCE(Proof Key for Code Exchange)流程要求客户端为公共客户端。
认证服务器端点
Protocol Endpoints :: Spring Authorization Server
包含OAuth2.1和Open Connect 1.0相关端点。
https://blog.csdn.net/qq_44005305/article/details/129029653
https://juejin.cn/post/7239953874950733884