外面有很多关于在你的应用程序中添加认证的信息，这很有帮助！但也令人不知所措。但也让人不知所措。它可能很难找到相关的和最新的信息。安全的最佳实践和技术都在变化，所以更新你的理解并跟上当前的最佳实践是一件好事。以下是我在复习知识和应用实施auth的经验时做的一些笔记。
优先选择OAuth 2.0和OpenID Connect
如果你要对一个新的应用程序实施认证，最好的做法是使用OAuth 2.0与OpenID Connect（OIDC）。OAuth 2.0与OIDC的结合为许多集成供应商提供了一致性，提供了标准化的信息访问方式和安全性。
让我们通过熟悉基础知识，为本帖的其余部分建立一个基线。这份《OAuth和OpenID Connect图解指南》非常好。
我非常喜欢把OAuth 2.0和OpenID Connect放在一起使用，因为它把 "Auths "分开，并给每个人增加了结构。我们从上面的博文中了解到，OAuth 2.0是为授权而设计的--对数据（资源）的访问。而我们了解到，OIDC是OAuth 2.0之上的一个薄层，增加了登录和配置文件信息。因此，认证是建立登录会话的行为，确认登录的用户是他们所说的人。现在我们可以具体到我们的词汇，并理解每个标准是如何补充对方的。
当你使用OpenID Connect时，别忘了你可以检查OpenID Connect发现文件，以获得端点和支持的用法的清单。你会看到下面的发现响应中对一些元数据的引用。
掌握了这些知识，让我们继续!
了解你的令牌
在OAuth 2.0和OpenID Connect中，有三种不同的令牌在发挥作用。根据你使用的授予类型（接下来会有更多的介绍），你可能没有所有的三个令牌。记住你正在使用的令牌的种类以及每个令牌的作用是很好的。这使得文档更容易解析，并且通过指定确切的令牌类型而不是只使用 "令牌 "一词，使团队对话不那么混乱。
 | ID令牌。从OpenID Connect返回的令牌，包含JSON Web令牌（JWT）格式的终端用户认证信息。 |
 | 访问令牌。从OAuth流返回的令牌，允许你访问资源。从Okta返回的访问令牌是JWT格式。 |
 | 刷新令牌。一个长期存在的令牌，你可以用它来交换短期的访问令牌。不是所有的授权类型都支持刷新令牌。 |
明智的申请
JWT具有向其添加自定义声称的能力。将自定义元数据直接添加到访问和ID令牌的有效载荷中，意味着你可以从一开始就获得为你的应用程序量身定做的属性，对吗？多么好的主意啊或者是这样吗？
自定义声明是强大的，但请记住，JWT的内容对任何拥有JWT的人都是可见的，比如外部开发人员调用你的系统，还有可能是最终用户。你不希望在添加私人信息时，期望它能安全地避免被窥视。你也不想在令牌中加入一堆自定义的要求，这样会使令牌变得臃肿。保持你的令牌轻量级，并使添加自定义索赔成为一个深思熟虑的决定。
使用正确的授予类型
我认为这是开发人员开始感到细节超载的地方。有不同的授予类型，根据调用者是谁和你正在进行的软件流程的类型，最佳的授予类型会发生变化。更加混乱的是，有些授予类型（或流程）是OAuth 2.0标准，有些是来自OpenID Connect。另外，还有更新的安全实践，并不是所有的博客文章都反映了当前的建议。呀!让我们去掉那些无关紧要的东西，专注于需要了解的东西。
首先，让我们从列出所有可用的拨款类型开始。我们将对每种类型进行高层次的定义。
 | 授权代码是一种授予类型，由源代码是私有的网络应用程序使用，例如服务器端的网络应用程序。获取访问令牌需要一个授权码和一个客户秘密。你可以通过使用PKCE使授权码授予类型对服务器端的网络应用更加安全。下面会有更多的介绍。 |
 | 客户端凭证是一种用于后端通信的授予类型，例如API到API。用户并不参与这个流程，所以没有一个ID令牌可用。 |
 | 设备代码是一种主要用于物联网和智能设备的授予类型。该流程通过外部设备（如智能手机应用程序或浏览器）委托用户认证和授权。设备代码作为Okta的早期访问功能可用，或者按照这篇文章的步骤在任何服务器上添加OAuth设备流。 |
 | 刷新令牌本身不是一个授予类型。它是应用程序可能收到的一个长效令牌，以获得对资源的更长时间的访问。如果授权服务器被配置为给应用程序刷新令牌，则授权代码、设备代码、混合和资源所有者密码流支持刷新令牌。 |
 | 代码交换的证明密钥（PKCE）是一个流程，用于创建一个秘密，在交换授权代码的令牌之前使用。这不是一个单独使用的授予类型，而是作为授权码流程的一个额外安全层。 |
 | Hybrid是OpenID Connect规范中的一组授予类型。code id_token 流程是最常见的，它结合了两种授予。它通过授权码授予返回一个访问令牌，通过隐式授予返回一个ID令牌。 |
 | Implicit是一种授予类型，曾经被推荐给本地和JavaScript应用程序。它是授权码授予的一个简化版本，但不需要为访问令牌交换授权码。由于存在安全风险，OAuth 2.0不再推荐这种授予类型，在即将发布的OAuth 2.1规范中也会放弃。 |
 | 资源所有者密码授予类型是由受信任的第一方客户使用的流程。由于应用程序直接处理凭证所涉及的风险，OAuth 2.0不再推荐这种授予类型，在即将到来的OAuth 2.1中，它将被放弃。可能有一些传统的应用程序需要这种流程，但这是使用它的唯一原因。 |
这仍然是一个很大的流量!还有很多要记住的。我们是忙碌的开发者因此，让我们把它简化为首选的补助。
这就好得多了!我们现在有合理数量的授权类型可以使用。设备代码、客户凭证和一个组合授予类型--带PKCE的授权代码。
 | 带PKCE的授权码是由 |
现在，我们有了一个最新的推荐授予类型列表，我们如何知道使用哪一个呢？你可能需要在一个完整的软件系统中使用多种授予类型，这取决于所涉及的场景和角色。你可能有一个SPA，一个本地应用程序，后端服务和流程，以及与外部各方的集成。其中每一个都需要考虑使用哪种授予类型。不要担心；通过检查发现端点，你就会知道你的身份提供者是否能够安全地处理你的需求！我们可以使用这个方便的工具。
尽可能地保持简单
我们很忙。而在我们的软件中添加认证和访问安全是基础性的，但它不是软件的唯一功能。作为产品开发者，我们需要把认证加入到系统中，并让我们放心，而不必担心所有的细节问题。为了使添加认证变得简单，使用已经处理所有这些琐碎细节的SDK。Okta有针对移动、前端和后端语言的SDK，可以快速上手。
那是什么？你说你的需求比简单地将Okta SDK添加到你的软件系统中要复杂一些？当您需要更多定制化的东西时，将OIDC认证的库纳入您的系统，让您在实现定制化需求的同时仍能遵循认证的最佳实践。
