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

Question

我正在尝试通过身份服务器摆脱困境。

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

1. ASP.NET MVC 5 应用程序
2. 一个 ASP.NET 网站 API
3. 一个windows服务实现

Int this blog post 我已经阅读了有关客户的一些详细信息。作者简单陈述：

OAuth 2 provides several "grant types" for different use cases. The grant types defined are:

1. Authorization Code for apps running on a web server
2. Implicit for browser-based or mobile apps
3. Password for logging in with a username and password
4. Client credentials for application access

Authorization Code 和 Implicit 有什么区别？这是否意味着 javascript 代码应该使用隐式？

说得对，我需要：

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

还有一个问题，我想在我的网络 api 中基于 Bearer Token 和一个简单的 apiKey 实现授权。两种类型可以凝聚吗？如何使用身份服务器实现 apiKey？

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

Answer 1

我尽力让这个答案简短（但我被迫添加了很多上下文来理解答案）

机密与 Public 客户

客户端（代表您请求访问权限的应用程序——MVC 应用程序、SPA 等）被归类为机密和 Public 客户端，基于它们使用授权服务器进行安全身份验证的能力（在我们的案例中为身份）服务器).

例如，Web 应用程序 (MVC App) 被认为是机密客户端，因为它是在安全服务器上实现的，并且能够使用授权服务器进行安全的客户端身份验证（通过后台通道——无需用户代理或 public频道）。 此外，它可以维护秘密令牌（本质上是客户端凭据，access_token 和刷新令牌），这些令牌不受 public 访问（例如，用户代理/资源所有者）

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

授权码授予

Oauth2 Spec 定义授权码授予为：

“The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.”

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

抽象而言——授权码流程具有以下顺序，

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

隐式授权

Oauth2 Spec 将隐式授权定义为：

“The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device”

Difference between Authorization Code and Implicit?

所以主要区别是：

• 在隐式授予中，客户端不会单独请求授权和访问令牌。
• 授权和访问令牌都传递给资源所有者，编码到重定向 URI
• 这会导致此处描述的安全漏洞 https://www.rfc-editor.org/rfc/rfc6749#section-10.16
• 由于这些安全隐患，根据体系结构，不会向 public 客户端颁发刷新令牌（它们无法维护客户端机密，因此 Access_token 和刷新令牌）

Do this means that implicit should be used for example by javascript code?

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

(为避免混淆，请跳过这部分 - 这种隐式流程有多种变体。总的来说，Oauth2 规范本质上是流动的，这导致我们沿着这些线构建了几个混合/自定义实现Oauth2 建议。OpenID-Connect 解决了一些问题，并且是建立在 Oauth2)

之上的相对较新（和成熟）的规范

the Password grant for ASP.NET MVC application –

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

Client credentials for Web API –

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

Authorization Code for the windows service?

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

Can both types cohesist? How do I implement apiKey by using Identity server?

我不能 100% 确定您的要求。但是，如果您可以 post 关于您想要实现的目标的更多详细信息和背景 here 。我很确定 Brock / Dominick 应该可以确认。