1.简介
在这篇文章中，从头开始实施OAuth 2.0和OpenID Connect服务器的开发人员（我）讨论了调查结果。基本上，实施的考虑点是在讨论中写出来的。因此，对于那些正在寻找“如何及时设置OAuth 2.0和OpenID Connect服务器”等信息的人来说，这不是一个文档。如果您正在寻找此类信息，请访问GitHub上的java-oauth-server和java-resource-server。使用这些，您可以在10分钟内启动授权服务器和资源服务器，发出访问令牌并使用访问令牌调用Web API，而无需设置数据库服务器。
偏见
我是Authlete，Inc。的联合创始人，该公司是一家在云端提供OAuth 2.0和OpenID Connect实施的公司，因此本文档可能会受到这种偏见的影响。因此，请在脑海中阅读本文档。但是，基本上，我将从纯工程师的角度来写这篇文章。
2.OAuth是否必要？
“我们希望在我们的公司网站上这样做。我们应该实施OAuth吗？“ - 这经常被问到。从本质上讲，这个问题是询问OAuth是什么。
我经常用来解释OAuth的一句话答案如下。
OAuth 2.0是一种框架，其中服务的用户可以允许第三方应用程序访问他/她在服务中托管的数据，而无需向应用程序透露他/她的凭据。
重要的一点是“不向第三方应用程序透露凭据”。OAuth就是为此而存在的。一旦理解了这一点，您可以通过检查是否满足以下条件来判断您是否应该为公司的服务准备OAuth服务器。
- 您的服务管理用户的数据。
- 您希望第三方为您的服务用户开发应用程序。
- 您不希望向第三方开发的应用程序透露用户凭据。
即使上述条件不满足且贵公司服务的应用程序仅为自制服务，如果您可能希望第三方在将来开发应用程序和/或建议应用程序，建议您实施OAuth服务器如果您想遵循Web API开发的最佳实践。
但是，混淆可能无法解决。当您想要让用户使用他们的外部服务帐户（如Facebook和Twitter）登录您的网站时。由于“OAuth身份验证”这一术语经常在此上下文中使用，因此您可能认为必须为您的服务实施OAuth。但是，在这种情况下，由于您的服务是使用外部服务实施的OAuth的客户端，因此您的服务本身不必实施OAuth。确切地说，您的服务必须编写代码以使用其他公司的OAuth。换句话说，从外部服务的角度来看，您的服务必须表现为OAuth客户端。但是，在此用例中，您的服务不必像OAuth服务器那样运行。也就是说，您不必实现OAuth服务器。
3.认证和授权
我解释了让人们感到困惑的术语 - “OAuth身份验证”。
每个解释都说“OAuth是授权规范，而不是身份验证规范。”这是因为RFC 6749（OAuth 2.0授权框架）明确指出认证“超出了本规范的范围。”以下段落摘自“ 3.1。RFC 6749中的“授权端点”。
授权端点用于与资源所有者交互并获得授权授权。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如，用户名和密码登录，会话cookie）超出了本规范的范围。
尽管如此，“OAuth身份验证”一词泛滥并使人们感到困惑。这种混淆不仅在商业方面，而且在工程师中也是如此。例如，“OAuth授权与身份验证”之类的问题有时会发布到Stack Overflow（我对问题的回答是这个）。
由术语，认证和授权（在OAuth的上下文中）处理的信息可以描述如下。
- 身份验证 - 谁是谁。
- 授权 - 谁授予谁谁的权限。
身份验证是一个简单的概念换句话说，它是对身份的确认。在网站上识别人的最流行方式是请求该人提供一对ID和密码，但还有其他方式，如使用指纹或虹膜的生物识别身份验证，一次性密码，随机数字表等。无论如何，无论使用何种方式，身份验证都是识别身份的过程。使用开发人员的话，可以表示为“身份验证是识别用户唯一标识符的过程”。
另一方面，授权是复杂的，因为涉及三个元素，即“谁”，“什么权限”和“对谁”。另外，令人困惑的是，在这三个要素中，识别“谁”是认证的过程。换句话说，授权过程包括认证过程作为一个部分的事实使事情变得混乱。
如果三个元素应该被开发人员使用的单词替换，“who”可以替换为“user”，“who”替换为“client application”。因此，OAuth上下文中的授权可以说是用户向客户端应用程序授予权限的过程。
下图描绘了到目前为止所解释的概念。
此图说明了授权页面（用户授予客户端应用程序权限的页面）中的哪些部分用于身份验证和授权。身份验证和授权之间的区别很明显。
现在，是时候谈论“OAuth身份验证”了。
因为授权过程包括认证过程作为一部分，所以授权意味着认证。因此，有些人开始使用OAuth进行身份验证。这是“OAuth身份验证”，并且由于“管理用户凭据的任务可以委托给外部服务”以及“新用户开始使用该服务的障碍因为用户而变得更低”等优点而迅速占据主导地位注册过程可以省略。“
OpenID的人对这种情况抱有怨恨。- 抱歉，我不知道他们是否真的有这种感觉，但至少我可以想象他们认为OAuth身份验证远远超出他们之前定义的规范级别，如OpenID 2.0和SAML。然而，不可否认的是，他们的规范并没有占上风，世界各地的开发人员都选择了OAuth身份验证的简易性。因此，他们在OAuth之上定义了一个新的身份验证规范OpenID Connect。OpenID Connect常见问题解答将关系描述为如下所示的等式。
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
由于这一点，OpenID Connect的身份验证可以在OAuth授权过程中同时执行。
由于业界的主要参与者一直致力于规范创建和主动实施（FAQ），OpenID Connect肯定会占上风。因此，OmniAuth等OAuth身份验证库将逐渐完成其角色。
但是，人们肯定会变得更加困惑，因为用于身份验证的OpenID Connect建立在用于授权的OAuth之上。很难解释，特别是在我的情况下，因为Authlete专注于授权，虽然它支持OpenID Connect，但它不会对身份验证做任何事情。在开始向客户解释产品本身之前，我总是要解释身份验证和授权之间的区别。
关于OAuth身份验证的问题，请阅读John Bradley先生的文章“OAuth for Authentication的问题”。在文章中他说：“这是一个安全漏洞，你可以开车穿过。”
“再说OAuth是一种认证标准。”Nat Sakimura先生和John Bradley先生。（来自https://twitter.com/ve7jtb/status/740650395735871488）
4. OAuth 2.0和OpenID Connect之间的关系
然而，到目前为止，所有内容只是这篇文章的序言。开发人员的技术内容从这里开始。第一个主题是OAuth 2.0和OpenID Connect之间的关系。
在我完成RFC 6749（OAuth 2.0授权框架）的实施之后，我注意到了OpenID Connect的存在。当我收集有关OpenID Connect的信息时，我认为我应该实现该功能，因此请阅读OpenID Connect Core 1.0和其他相关规范。在阅读之后，我得出的结论是“所有人都应该从头开始重写”。
OpenID Connect网站称“OpenID Connect 1.0是一个基于OAuth 2.0协议的简单身份层。”这给人的印象是OpenID Connect可以在现有的OAuth 2.0实现之上轻松无缝地实现。然而，事实却完全不同。恕我直言，OpenID Connect实际上是OAuth 3.0。
有许多与OpenID Connect相关的规范，它们令人费解，难以破译它们。在我能够掌握整个画面之前，我几乎疯了，不得不读了三遍。与OpenID Connect规范相比，RFC 6749可以说很容易。
5.响应类型
特别是，与现有实现冲突的是处理请求参数response_type的方法。可以肯定的是，RFC 6749声明请求参数可能需要多个值，但这是将来的可能性。如果我们直接读取RFC 6749，则response_type是代码或令牌。几乎不可能想象这两个是同时设置的。这是因为该参数用于确定处理来自客户端应用程序的请求的流程。具体而言，当response_type的值是代码时使用授权代码流，并且当值是token时使用隐式流。谁能想象这些流量是混合的？即使可以想象它，我们应该如何解决流量之间存在的冲突？例如，授权代码流要求将响应参数嵌入到重定向URI（4.1.2。授权响应）的查询部分中，而隐式流要求将响应参数嵌入到片段部分中（4.2.2。访问令牌）响应），并不能同时满足这些要求。
但是，OpenID Connect已将id_token添加为response_type的新值，并明确允许将code，token和id_token的任意组合作为response_type的值。此外，也没有添加。详情见“3。身份验证“OpenID Connect Core 1.0和OAuth 2.0多响应类型编码实践”。
它需要进行重大更改才能修改在假定选择或选择的情况下编写的现有代码，以便它可以处理可能值和混合流的任意组合。因此，如果将来有可能支持OpenID Connect，OAuth库的实现者应该从头开始用OpenID Connect编写它。换句话说，现有的OAuth库无法在不进行重大修改的情况下支持OpenID Connect。
例如，Spring Security OAuth。此库尚未支持OpenID Connect（截至2016年6月）。对于要支持OpenID Connect的库，首先，请求参数response_type必须能够采用除代码和令牌之外的其他值。对它的请求被列为“问题＃619处理其他response_types”，但它尚未得到解决，并且该主题的最后一条评论是“任何评论都非常受欢迎，因为事实证明（正如我预测的那样）a大型重构练习。“我阅读了一些相关的源文件，发现支持OpenID Connect需要进行大的修改才是真的。除非一些公司在财务上支持该项目，否则我担心该项目需要很长时间才能支持OpenID Connect。
顺便说一句，我也想提到Apache Oltu。该项目声称它支持OpenID Connect，但我的猜测是初始实现仅支持OAuth 2.0，并且在稍后阶段添加了OpenID Connect支持。我认为这样的原因是OAuth 2.0（org.apache.oltu.oauth2）的包和OpenID Connect（org.apache.oltu.openidconnect）的包是隔离的。但是，这种方法会破坏架构。例如，OpenIdConnectResponse类是OAuthAccessTokenResponse的后代是不合适的，因为包含ID令牌的响应不一定包含访问令牌。其他示例是存在名为OAuthClientRequest.AuthenticationRequestBuilder的类（由于某些原因而不是“授权”但是“身份验证”）以及存在GitHub特定的类GitHubTokenResponse。Apache Oltu的架构至少给我带来了问题。我不知道有关该项目的细节，但在我个人看来，它注定要缩小。
6.客户端应用程序的元数据
正如在RFC 6749的客户端注册中明确写出的那样，客户端应用程序必须在发出授权请求之前提前注册到目标授权服务器。因此，在典型情况下，授权服务器的实现者定义数据库表以存储关于客户端应用程序的信息。
要确定表应该具有哪些列，实现者通过阅读规范来列出项目。例如，阅读RFC 6749将使您意识到至少需要以下项目。
- Client ID
- Client Secret
- Client Type
- Redirect URIs
除此之外，实现者可以添加更多属性。例如，“应用程序名称”。
即使您通过RFC 6749进行搜索，客户端应用程序的属性也没有那么多，因此存储客户端应用程序属性的数据库表的列数不会变大 - 这样的好日子已经因为出现了OpenID Connect。客户端应用程序应具有的许多属性列在2. OpenID Connect动态客户端注册1.0的客户端元数据中。以下是清单。
- redirect_uris - 客户端使用的重定向URI值。
- response_types - 客户端声明它将自己限制为使用的response_type值。
- grant_types - 授权客户端声明它将限制自己使用的类型。
- application_type - 应用程序的种类。
- 联系人 - 负责此客户的人员的电子邮件地址。
- client_name - 要呈现给最终用户的客户端的名称。
- logo_uri - 引用客户端应用程序徽标的URL。
- client_uri - 客户端主页的URL。
- policy_uri-依赖方客户端向最终用户提供的URL，以了解如何使用配置文件数据。
- tos_uri-依赖方客户提供给最终用户的URL，以了解依赖方的服务条款。
- jwks_uri-客户端的JSON Web密钥集文档的URL。
- jwks - 客户端的JSON Web Key Set文档，按值传递。
- sector_identifier_uri - 使用https方案的URL，用于由OP计算伪名标识符。
- subject_type - 要求对此客户的响应的subject_type。
- id_token_signed_response_alg - 签署发给此客户端的ID令牌所需的JWS alg算法。
- id_token_encrypted_response_alg - 加密发给此客户端的ID令牌所需的JWE alg算法。
- id_token_encrypted_response_enc-加密发给该客户端的ID令牌所需的JWE enc算法。
- userinfo_signed_response_alg-签署UserInfo响应所需的JWS alg算法。
- userinfo_encrypted_response_alg - 加密UserInfo响应所需的JWE alg算法。
- userinfo_encrypted_response_enc - 加密UserInfo响应所需的JWE enc算法。
- request_object_signing_response_alg - 必须用于签署发送给OP的请求对象的JWS alg算法。
- request_object_encryption_alg - RP声明它可以用于加密发送给OP的请求对象的JWE alg算法。
- request_object_encryption_enc - JWE enc算法，RP声明它可以用于加密发送给OP的请求对象。
- token_endpoint_auth_method-请求端点的请求客户端身份验证方法。
- token_endpoint_auth_signing_alg - 必须用于对JWT进行签名的JWS alg算法，该JWT用于在令牌端点对private_key_jwt和client_secret_jwt身份验证方法的客户端进行身份验证。
- default_max_age - 默认最大认证年龄。
- require_auth_time - 布尔值，指定是否需要ID令牌中的auth_time声明。
- default_acr_values - 默认请求的身份验证上下文类参考值。
- initiate_login_uri - 使用https方案的URI，第三方可以使用该方案来启动RP的登录。
- request_uris - 由RP预先注册以在OP上使用的request_uri值。
因此，客户端应用程序的数据库表应该能够存储这些信息。此外，应该注意的是，允许本地化某些属性（例如client_name，tos_uri，policy_uri，logo_uri和client_uri）（2.1。元数据语言和脚本）。需要额外考虑数据库表设计来存储本地化属性值。
以下小节是我对客户应用程序属性的个人意见。
6.1 客户类型
我担心定义规范是一种错误2. OpenID Connect动态客户端注册1.0的客户端元数据不包含“客户端类型”。我认为这样做的原因是，当我们实现授权服务器时，必须考虑两种客户端类型之间的区别，“机密”和“公共”（在2.1。客户端类型的RFC 6749中定义）。事实上，“客户端类型”被列为要在2.注册RFC 6749的客户端注册的客户端属性的示例如下。
...注册可以依赖于其他方式来建立信任并获得所需的客户端属性（例如，重定向URI，客户端类型）。
如果这不是错误，则必须就动态客户端注册注册的客户端应用程序的客户端类型达成共识。但是，我无法在相关规范中找到此类信息。
无论如何，我认为在为客户端应用程序定义数据库表时，应该存在客户端类型的列。
您可以在问题991中找到关于此的一些讨论。
6.2。申请类型
根据规范，application_type是可选属性。application_type的预定义值是native和web。如果省略，则将web用作默认值。
如果省略时使用默认值，则自然结果是客户端应用程序的应用程序类型必须是本机和Web。因此，您可能希望在application_type的列中添加NOT NULL。但是，Authlete的实现不敢添加NOT NULL并允许NULL。
原因是我不确定应用于每个OAuth 2.0客户端的OpenID Connect动态客户端注册1.0中定义的application_type所施加的重定向URI值的限制。
使用OAuth隐式授权类型的Web客户端必须仅使用https方案注册URL作为redirect_uris;他们不能使用localhost作为主机名。本机客户端必须仅使用自定义URI方案或URL使用http：scheme注册redirect_uris，并使用localhost作为主机名。
2年前，我发布了一个问题“应用程序类型（OpenID Connect）是否与客户端类型（OAuth 2.0）对应？”到Stack Overflow，但我无法得到任何答案。所以我自己调查和回答。如果有兴趣请看。
6.3。客户秘密
客户秘密的长度应该是多长时间？
例如，“OpenAM管理指南”使用密码作为客户端机密值的示例。下面是12.4.1的截图。将OpenAM配置为授权服务器和客户端。
似乎OpenAM允许用户使用短字符串作为客户端密钥。
另一方面，在Authlete的实现中，客户端机密自动生成并变得像下面那样长。
GBAyfVL7YWtP6gudLIjbRZV_N0dW4f3xETiIxqtokEAZ6FAsBtgyIq0MpU1uQ7J08xOTO2zwP0OuO3pMVAUTid
这个长度的原因是我想支持512位的对称签名和加密算法。例如，我想支持HS512作为JWS的签名算法。因为客户机密码必须具有512位或更多的熵以支持HS512，所以上述示例的长度是86，这是使用base64url编码512位数据的结果。
关于对称签名和加密算法的熵，OpenID Connect Core 1.0中的16.19对称密钥熵如下所述。
在10.1节和10.2节中，密钥是从client_secret值派生的。因此，当与对称签名或加密操作一起使用时，client_secret值必须包含足够的熵以生成加密强密钥。此外，client_secret值还必须至少包含所使用的特定算法的MAC密钥所需的最小八位字节数。因此，例如，对于HS256，client_secret值必须包含至少32个八位字节（并且几乎可以肯定应该包含更多，因为client_secret值可能使用受限制的字母表）。
并且，3.1。RFC 7518（JSON Web算法）中的JWS的“alg”（算法）头部参数值指出必须支持HS256（使用SHA-256的HMAC）作为JWS的签名算法。作为合乎逻辑的结果，任何声称符合OpenID Connect的实现都需要生成具有256位或更多熵的客户机密钥。
6.4。签名算法
id_token_signed_response_alg列在“2。“OpenID Connect动态客户端注册1.0的客户端元数据”。它表示客户端应用程序要求授权服务器用作ID令牌的签名算法的算法。如上所述，有效值列在RFC 7518中，应注意不允许任何值。如果在注册时省略id_token_signed_response_alg的值，则使用RS256。
userinfo_signed_response_alg也是客户端应用程序要求授权服务器使用的签名算法。该算法用于签署从UserI返回的信息
这是偏离主题的，但是为nv-websocket-client（日语信息）创建了一个问题，这是一个用于Java的WebSocket客户端库我在GitHub上向公众开放。问题是一个功能改进的提议，表明当开发人员同时调用setSSLContext（）方法和setSSLSocketFactory（）方法时，库有一个警告机制。之所以提出这个提案，是因为记者对这两种方法的不正当行为感到不安。我的回答是它在JavaDoc中明确写出了当调用这两个方法时哪个设置优先，并且这样的插入检查会使WebSocketFactory类难以使用。然后，反应是“在调用这两种方法之前，先没有详细阅读文档，这是我的错。但是，您认为有多少其他开发人员会在犯同样错误之前先详细阅读文档？“
哦，如果开发人员由于他/她没有阅读文件的原因而浪费时间在自制错误上，这只是一个当之无愧的惩罚......
帮助那些不阅读文件的人的试验将是无止境的。即使库阻止了alg = none的签名，这些工程师也会毫不犹豫地将私钥包含在通过授权服务器的JWK Set端点发布的JWK集中。为什么？你认为那些不读文件的人可以注意到JWKSet类的toPublicJWKSet（）方法的存在（在Nimbus JOSE + JWT库中）并理解方法的含义吗？可能，他们天真地说，“是的，我可以创建一个JWKSet类的实例。我们发布吧！我已经完成了JWK Set端点的实现！“
不参考RFC等主要来源的工程师无法发现他们找到的答案中的错误，并毫无疑问地相信答案。但是，工程师必须避免阅读RFC以成为真正的工程师。
要成为真正的工程师，请不要避免阅读RFC。只搜索技术博客和Stack Overflow寻找答案永远不会把你带到正确的地方。
6.5。Client Application Developer
一些开源授权服务器提供了一种机制，可以动态注册客户端应用程序，如HTML表单（ForgeRock的OpenAM）和Web API（MITRE的MITREid Connect）。但是，似乎只有授权服务器的管理员才能注册客户端应用程序。但是，理想的方法是创建类似于Twitter的应用程序管理控制台，让开发人员登录，并提供一个环境，让每个开发人员都可以注册和管理他/她自己的客户端应用程序。为此，客户端应用程序的数据库表应该有一个包含开发人员唯一标识符的列。
它经常被遗忘，因为实现授权服务器本身很麻烦，但是还需要提供管理客户端应用程序的机制，以便向公众开放Web API。如果Web API的预期用户仅限于封闭组，则授权服务器的管理员可以在每次请求他/她时注册客户端应用程序。事实上，有一家公司的管理员为每个注册请求手动键入SQL语句。但是，如果要向公众开放Web API，此类操作将无法运行，您将意识到必须为客户端应用程序提供合适的管理控制台。如果您成功确保了开发授权服务器和Web API的预算，但忘记了为客户端应用程序确保管理控制台的预算，则会导致“已实现Web API但无法向公众开放”。
作为此类管理控制台的示例，Authlete为上述用例提供了开发者控制台。Authlete本身不管理开发人员帐户，但通过名为“开发人员身份验证回调”的机制，其帐户由Authlete客户管理的开发人员可以使用开发人员控制台。因此，Authlete客户不必为客户端应用程序开发管理控制台。
7.访问令牌
7.1。访问令牌表示
如何表示访问令牌？有两种主要方式。
作为无意义的随机字符串。与访问令牌相关联的信息存储在授权服务器后面的数据库表中。
作为一个自包含的字符串，它是通过base64url或类似的东西对访问令牌信息进行编码的结果。
在这些方式之间进行选择将导致后续差异，如下表所述。
如果访问令牌是随机字符串，则每次都需要查询授权服务器以获取有关访问令牌的信息。相反，如果访问令牌本身包含信息，则无需查询授权服务器。这使得自包含样式听起来更好，但是因为必须对授权服务器进行查询以检查访问令牌是否已被撤销，即使采用自包含样式，在任何情况下，网络通信也是如此。每次客户端应用程序呈现访问令牌时都需要。
自包含样式中的繁琐之处在于，每次请求访问令牌撤销时，我们必须添加表示“已撤销”的记录，并且必须保留此类记录，直到访问令牌到期为止。否则，如果删除了记录，则撤销的访问令牌将被复活并再次生效（如果尚未达到原始到期日期）。
相反，在随机字符串样式的情况下，可以简单地通过删除访问令牌记录本身来实现访问令牌撤销。因此，由于任何意外，撤销访问令牌无法复活。此外，不会发生在独立风格中观察到的负面影响“撤销增加记录”。
要启用访问令牌吊销，即使在自包含样式的情况下，也必须为访问令牌分配唯一标识符。否则，无法分辨哪个访问令牌已被撤销。换句话说，授权服务器采用自包含样式但不为访问令牌分配唯一标识符是授权服务器，它不能撤销访问令牌。它可能是实现策略之一，但是这样的授权服务器不应该发出长期访问令牌，也不应该发出刷新令牌。
“无法撤销访问令牌的授权服务器？！”，您可能想知道。但是，这种授权确实存在。某个全球大型系统集成商收购了一家公司，并正在使用被收购公司的产品开发授权服务器，但在后期阶段，系统集成商及其客户注意到授权服务器无法撤销访问令牌。当我听到这个故事时，我猜想授权服务器会发出没有唯一标识符的自包含样式的访问令牌。
自包含的样式看起来很好，因为有一些优点，例如“无需查询授权服务器来提取访问令牌的信息”和“无需在授权服务器端维护访问令牌记录”，但是当你考虑访问令牌撤销，有讨论的余地。
7.2。访问令牌删除
为防止数据库无限增长，应定期从数据库中删除过期的访问令牌。
请求授权服务器不必要地发出访问令牌的客户端应用程序是麻烦制造者。虽然他们已经有一个尚未过期的访问令牌，但他们会重复丢弃这样一个有效的访问令牌并请求新的令牌。如果发生这种情况，则会在数据库中累积未使用但无法删除的访问令牌（因为它们尚未过期）。
要防止出现这种情况，请将访问令牌最后一次使用的时间戳保存到数据库中，以及访问令牌到期的时间戳，并定期运行程序，以便长时间删除未使用的访问令牌。当然，它取决于服务的特性是否可以在未过期时删除未使用的访问令牌。
在此之前，我遇到了一位工程师，他在某个大公司的OAuth实施项目中工作，而他却属于该公司。他告诉我，系统的构建没有考虑访问令牌的删除，因此系统的数据库可能拥有数以亿计的访问令牌。吓人，可怕。当开发生成某个东西的系统时，应该同时考虑删除生成的东西的时间。
