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

Question

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

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

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

在这篇博文中,我已经阅读了一些关于客户的细节.作者简单地说:

OAuth 2为不同的用例提供了几种"授权类型".定义的授权类型是:

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

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

说我需要:

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

另外一个问题,我想基于Bearer Token和简单的apiKey在我的web api中实现授权.这两种类型都可以融合吗？如何使用Identity Server实现apiKey？

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

Answer 1

我尽力保持这个答案简短(但我被迫添加了很多背景来理解答案)

机密与公共客户

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

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

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

授权代码授予

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

"授权代码授予类型用于获取访问令牌和刷新令牌,并针对机密客户端进行了优化.由于这是一个基于重定向的流程,因此客户端必须能够与资源所有者的用户代理(通常是Web浏览器)进行交互,并且能够从授权服务器接收传入请求(通过重定向)."

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

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

• 资源所有者使用授权服务器对(通过用户代理)进行身份验证并获取authorization_code
• 资源所有者向客户端提供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 Server实现apiKey？

我不是100%肯定你的要求.但是如果你可以张贴一些有关你想达到什么更多的细节和背景在这里.我很确定Brock/Dominick应该能够证实.