OAuth 2.1 的幕后花絮
每个 Web 开发人员都应该了解 OAuth 2.0 PKCE 流程。
每个 Web 开发人员都应该了解 OAuth 2.0 PKCE 流程。在高层次上，流程涉及以下内容：
- 注册客户端应用程序
- 创建用户并将用户与客户端应用程序相关联
- 创建密码验证器和密码挑战 [PKCE]
- 构建授权 URL 并将用户重定向到授权服务器。
- 成功登录后，用户被重定向回客户端。验证状态。
- 将授权代码和代码验证器交换为访问令牌
使用以下游乐场获得第一手经验。
[
OAuth 2.0 PKCE 流程
在开始流程之前，您需要注册一个客户端并创建一个用户。注册会给你一个客户……
www.oauth.com
](https://www.oauth.com/playground/authorization-code-with-pkce.html)
OAuth 2.0 和 OpenID Connect 帮助 Web 应用程序：
- 通过 ID 令牌识别用户
- 通过访问令牌访问 API
幕后是关于如何制作这些代币的？
- 对称和非对称加密
- 加密哈希函数
- JSON Web 令牌（JWT，发音为 jot）
- JWT 签名验证
- JSON Web 密钥集
- PKCE
这种理解将帮助开发人员获得知识并欣赏加强流程的工作。
对称加密
- 对称加密使用密钥（密码）来加密内容。
- 要解密对称加密的数据，您需要相同的密钥。
- 常用的实现是高级加密标准 (AES)。
- AES 密钥的大小可以是 128、192 或 256 位。
每次运行的加密文本都会有所不同——由 Initialization Vector 提供。
非对称加密：公钥密码学
- 公钥密码术涉及一对称为 公钥 和一个 私钥
- 私钥是秘密。可以发布相应的公钥。
- 常用的实现是 Rivest-Shamir-Adelman (RSA) 算法。
- 现在的 RSA 公钥对大小为 2048 位（256 字节）。
默认情况下，RSA 加密文本在每次运行时都会有所不同。
对称加密和（非对）非对称加密
- 对称加密比非对称加密要快。
- 但是，“共享秘密”是对称方法的固有问题。如果您必须与一个人共享密钥，您可以拨打电话、发短信或通过某种方式进行交流。如果您必须与成千上万的人分享，这是不切实际的。此外，与多个人分享秘密不再是秘密。
- 非对称方法解决了共享秘密的问题。
检查 SSL/TLS 握手过程以了解动态。
Source: https://www.ssl.com/article/ssl-tls-handshake-overview/
校验和
- 校验和散列函数生成散列码以检查给定数据的完整性。
- 我们希望检查完整性的每个字节都应该用于计算校验和。
- 散列函数必须是确定性的，这意味着相同的消息总是会产生相同的散列。
- 解码生成的哈希码以获得原始内容是不可能的。目的只是为了证明其真实性。
加密哈希函数
“任何有权访问文件的人都可以生成 MD5 校验和。闯入站点或执行中间人攻击的攻击者可以轻松更改 MD5 校验和，使其与受损文件匹配。” — 堆栈溢出
数字签名克服了上述弱点。
签约
- 创建内容的哈希码以确保数据完整性。
- 使用私钥加密哈希码（非对称加密）。加密的哈希码称为数字签名。
验证
- 使用公钥（非对称加密）解密数字签名。输出将是哈希码。
- 验证哈希码以确保数据完整性。
JSON 网络令牌
JSON Web Token (JWT) 是一个开放标准 ( RFC 7519 )，它定义了一种紧凑且独立的方式，用于在各方之间安全地传输信息作为 JSON 对象。这些信息可以被验证和信任，因为它是 数字签名 .
RS256 是流行的算法之一。
- 签名算法为 RSASSA-PKCS1-v1_5 ( RS ）。
- 哈希算法是 SHA256 ( 256 ）。
Image Source: https://community.auth0.com/t/rs256-vs-hs256-jwt-signing-algorithms/58609
使用 JWT Playground 了解 JWT 有效负载、签名及其验证过程。
[
智威汤逊
JSON Web Token (JWT) 是一种紧凑的 URL 安全方式，用于表示要在两方之间传输的声明。这…
jwt.io
如果你已经到了这个阶段，请拍拍自己的背。要进一步探索，请在 Okta 中创建一个开发者帐户（免费帐户）。
[
Okta 开发人员
Okta 的开发人员版提供了为您的公司评估和探索 Okta 所需的一切。高达 100 MAU 与…
developer.okta.com
](https://developer.okta.com/signup/)
Okta 默认创建一个授权服务器。导航路径是 Security >> API >> Authorization Servers >> default。
根据 OAuth 2 标准，每个授权服务器都应该发布元数据 URI。
JWKS 是我们的下一个主题。
[ https://dev-xxxxxxx-okta.com/oauth2/default/.well-known/oauth-authorization-server](https://dev-68546164.okta.com/oauth2/default/.well-known/oauth-authorization-server) "发行人": "https://dev-xxxxxxxx.okta.com/oauth2/default", "authorization_endpoint": "https://dev-xxxxxxxx.okta.com/oauth2/default/v1/authorize", "token_endpoint": "https://dev-xxxxxxxx.okta.com/oauth2/default/v1/token", "registration_endpoint": "https://dev-xxxxxxxx.okta.com/oauth2/v1/clients", **“jwks_uri”：“https://dev-xxxxxxxx.okta.com/oauth2/default/v1/keys”** ,
JSON Web 密钥集
JWT 的签名验证需要一个公钥。根据所选算法，还需要其他值。为了标准化此信息的共享，引入了 JSON Web Key ( RFC 7517 ）。
Sample JWKS
让我们连接所有的点：
- ID 令牌和访问令牌是 JWT。
- 只有当签名可以被验证时，JWT 才会被信任。 JWKS 通过提供与您的 JWT 相关的公钥发挥着至关重要的作用。
- 此外，还应验证 JWT 声明。在接受有效负载之前，应遵守到期。
最后，让我们思考一下使用 Okta 的 PKCE（可选部分，请随意跳过）。
使用授权码授予的 OAuth 2.0 公共客户端是
容易受到授权码拦截攻击。这个
规范描述了攻击以及减轻攻击的技术
通过使用 Proof Key 进行代码交换来抵御威胁
（PKCE，发音为“pixy”）—— RFC 7636
请阅读博客以获取有关“使用 PKCE 流程的 OAuth 2.0 授权代码”的更多详细信息。相反，我将分享有关如何生成 PKCE 以及如何在我们的本地设置中测试运行 Auth Flow 的详细信息。
[
使用 PKCE 流实现 OAuth 2.0 授权代码
想象两个反向连接的杠杆。也就是说，随着一个上升，另一个下降。一个杠杆是用户……
developer.okta.com
](https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce)
在 Okta 开发者帐户中创建以下内容：
- 创建客户端应用程序。
- 在 Okta 通用目录中创建人员/组。
- 将人员与客户端应用程序相关联。
[
使用重定向模型将用户登录到您的 SPA
使用 Okta 的重定向模型（打开一个新窗口）将身份验证添加到您的单页应用程序。此示例使用 Okta 作为…
developer.okta.com
将访问令牌复制并粘贴到 https://jwt.io/ .
现在，每个方面都会清楚：
- 签名已验证。
- jwt.io 是如何知道公钥的？检查网络选项卡。将有两个网络请求——一个用于元数据 URI，第二个用于 JWKS。
更多内容在 ** 纯英语.io** .注册我们的 ** 免费每周通讯** .跟着我们 ** 推特** , ** 领英** , ** YouTube** ， 和 ** 不和谐** .对增长黑客感兴趣？查看 ** 电路** .
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/38858/53132311
标签：加密,JWT,https,okta,OAuth,2.1,com,花絮 From： https://www.cnblogs.com/amboke/p/16722246.html