Thinktecture身份服务器客户端选择和实施

Question

我正试图通过身份服务器让我的脑袋脱离云端。

我想实现身份服务器项目以进行身份​​验证

1. ASP.NET MVC 5应用程序
2. ASP.NET Web API
3. Windows服务实施

Int this blog post我已经阅读了有关客户的一些细节。作者简单地说：

  

OAuth 2提供了几种＆＃34;授权类型＆＃34;针对不同的用例。该   定义的授权类型是：

     

  
1. 在网络服务器上运行的应用的授权码
  
2. 隐含基于浏览器或移动应用
  
3. 使用用户名和密码登录的密码
  
4. 应用程序访问的客户端凭据
  

授权码和隐式之间有什么区别？这是否意味着隐式应该用于例如javascript代码？

说我需要是正确的：

1. ASP.NET MVC应用程序的密码授予
2. Web API的客户端凭据
3. Windows服务的授权码？

另外一个问题，我想基于Bearer Token和简单的apiKey在我的web api中实现授权。这两种类型都可以融合吗？如何使用身份服务器实现apiKey？

非常感谢，如果这些都是愚蠢的问题，请原谅。

Answer 1

我尽力保持这个答案的简短（但我不得不添加很多背景来理解答案）

机密与公共客户

客户端（代表您请求访问的应用程序 - MVC App，SPA等）根据其使用授权服务器（在我们的示例中为Identity Server）进行安全身份验证的能力分类为机密客户端和公共客户端。

例如，Web应用程序（MVC App）被认为是机密客户端，因为它是在安全服务器上实现的，并且能够通过授权服务器进行安全的客户端身份验证（通过反向通道 - 无需用户代理或公共渠道的参与） 。 此外，它可以维护保护免受公共访问的秘密令牌（基本上是客户端凭证，access_token和刷新令牌）（例如，由用户代理/资源所有者）

然而，基于用户代理的应用程序（SPA）和本机应用程序（移动应用程序）被视为公共客户端。这是因为资源所有者可以轻松访问协议数据和客户端凭据。

授权码授权

Oauth2 Spec将授权代码授权定义为：

  

“授权代码授予类型用于获取两种访问权限   令牌和刷新令牌，并针对机密客户进行了优化。   由于这是基于重定向的流程，因此客户端必须具备此功能   与资源所有者的用户代理（通常是网络）进行交互   浏览器）并能够接收传入的请求（通过重定向）   来自授权服务器。“

简单来说，授权代码流程针对通过用户代理（浏览器）与资源所有者进行交互的机密客户端进行了优化，该用户代理能够接收和重定向来自Auth Server（Identity Server）的传入请求。

在抽象术语中 - 授权代码流具有以下顺序，

• 资源所有者通过授权对（通过 - 用户代理）进行身份验证 服务器并获取authorization_code
• 资源所有者提供 授权客户端的代码（从重定向后通过用户代理） 授权服务器）
• 客户端使用授权服务器进行身份验证（通过反向通道请求）并交换Authorization_code以获取access_token
• access_token存储在客户端中，资源所有者被重定向到适当的资源
• 由于Client（MVC App）具有access_token，因此可以请求刷新 来自授权服务器的令牌（如果需要）。
• 但重要的一点是 - 在授权代码流中，资源所有者永远不会看到（或有权访问）Access_token。客户安全地存储它。

隐含授权

Oauth2 Spec将隐式授权定义为：

  

“隐式授权类型用于获取访问令牌（它没有   支持刷新令牌的发布）并针对公众进行了优化   已知操作特定重定向URI的客户端。这些客户   通常使用脚本语言在浏览器中实现   作为JavaScript。

     

由于这是基于重定向的流，因此客户端必须   能够与资源所有者的用户代理进行交互   （通常是Web浏览器）并且能够接收传入的请求   （通过重定向）来自授权服务器。

     

不同于   授权代码授予类型，客户端将其分开   请求授权和访问令牌，客户端   作为授权请求的结果接收访问令牌。

     

隐式授权类型不包括客户端身份验证，以及   依赖于资源所有者的存在和注册   重定向URI。因为访问令牌被编码到   重定向URI，它可能会暴露给资源所有者和其他人   驻留在同一设备上的应用程序“

  

授权码与隐式之间的区别？

所以主要区别在于：

• 在隐式授权中，客户端不会单独请求授权和访问令牌。
• 授权和访问令牌都传递给资源所有者，编码为重定向URI
• 这会导致此处描述的安全漏洞https://tools.ietf.org/html/rfc6749#section-10.16
• 由于这些安全隐患，通过体系结构，不会向公共客户端（无法保持客户端密钥，因此无法访问Access_token和刷新令牌）发布刷新令牌。

  

这意味着隐式应该用于例如javascript   码？

是。由于上面讨论的细节和通常的做法，大多数JS / SPA使用Oauth2隐式流来保护应用程序。

（为了避免混淆，请跳过这一部分 - 这个隐含的流程有几种变化。总的来说，Oauth2规范本质上是流动的，这导致我们按照Oauth2建议的方式构建了几个混合/定制实现。 OpenID-Connect解决了一些问题，并且是在Oauth2 之上构建的相对新的（和成熟的）规范。

  

ASP.NET MVC应用程序的密码授予 -

密码授予旨在用于资源所有者与客户端具有强信任关系的场景（例如本机应用程序）。对于此用例，建议的授权类型将是授权代码流。

  

Web API的客户端凭据 -

你是对的。当应用程序本身也是资源所有者时使用客户端凭据授予类型

  

Windows服务的授权码？

由于规范中的上述原因（用户代理重定向要求等），授权代码流程不适合此处。根据Windows服务的类型，我将使用客户端凭据或密码授予类型

  

这两种类型都可以融合吗？如何使用Identity实现apiKey   服务器

我不是100％肯定你的要求。但是，如果你可以发布一些关于你想要达到的目标的更多细节和背景here。我非常肯定Brock / Dominick应该能够证实。