我尽力保持这个答案短（但我不得不添加大量的上下文做出回答的意义上）

保密与公开的客户端

客户端（请求您的名义访问的应用程序 - MVC应用程序，SPA等）被归类为基于其与授权服务器（本例中的Identity Server）安全验证能力机密和公共机构提供服务。

例如，Web应用程序（MVC应用程序）被认为是机密的客户，因为它是安全服务器，并能够进行安全的客户端认证与授权服务器上实现（通过反向通道 - 无需用户代理或公共频道的参与） 。
此外，它可以保持秘密凭证（主要是客户端凭据，和的access_token刷新令牌），这是从公共接入保护（例如，通过用户代理/资源拥有者）

然而，基于用户代理程序（SPA）和本机应用程序（移动应用）被认为是公共机构提供服务。这是因为协议的数据和客户端证书是由资源所有者方便。

授权code格兰特

的oauth2规格定义授权code格兰特为：

  

授权code交付式用来获得两个访问
  令牌和刷新令牌，并为客户保密的优化。
  由于这是一种基于重定向流时，客户端必须能够
  与资源所有者的用户代理交互（通常为Web
  浏览器）和能够接收传入的请求（通过重定向）
  从授权服务器。

块引用>

这只是意味着，授权code流量的机密客户通过用户代理与资源所有者进行交互（浏览器）能够接收和重定向从认证服务器（标识服务器）的传入请求进行了优化。

在抽象的术语 - 授权code流动具有下列序列，

• 资源拥有者进行身份验证（通过-user剂）有授权
  服务器并获取一个authorization_ code


• 资源拥有者提供
  Authorization_ code到客户端（通过用户代理从后重定向
  授权服务器）


• 客户端与服务器的授权（通过反向信道要求）和交流Authorization_ code认证拿到的access_token


• 中的access_token存储在客户端和资源所有者将被重定向到相应的资源


• 由于客户端（MVC应用程序）具有的access_token，它可以要求刷新
  （如果需要）从授权服务器令牌。


• 虽然很重要的一点 - 在授权code流量资源所有者从来没有看到（或有权访问）ACCESS_TOKEN。客户端将其存储安全。

隐拨款

的oauth2规格定义隐批为：

  

隐式许可类型用于获得访问令牌（它不
  支持发行刷新令牌），并公开进行了优化
  已知以操作特定重定向的URI的客户端。这些客户端
  使用脚本语言，例如在浏览器的典型实现
  如JavaScript。

  
  

由于这是一个基于重定向流量，客户端必须
  能够与资源所有者的user-agent交互
  （一般的web浏览器）和能够接收传入的请求的
  （通过重定向）从授权服务器。

  
  

不像
  授权code补助型，其中客户端发出单独的
  授权和访问令牌，客户端的请求
  接收该访问令牌作为授权请求的结果。

  
  

隐式类型补助不包括客户端身份验证，并
  依赖于资源所有者的presence和登记
  重定向URI。因为访问令牌是连接coded到
  重定向的URI，它可暴露于资源所有者和其他
  驻留在同一设备

上的应用程序
块引用>

  

授权code和隐性的区别？

块引用>

因此​​，主要区别在于：

• 在隐批，客户端不作出授权和访问令牌单独的请求。


• 授权和访问令牌传递到资源所有者，连接coded到重定向URI


• 这导致这里 https://tool​​s.ietf.org/html描述的安全漏洞/rfc6749#section-10.16


• 由于这些安全隐患，通过架构一个刷新令牌将不会发行予公众客户（这是不能维持客户的秘密，因此ACCESS_TOKEN和刷新令牌）

  

执行。这意味着隐含应当由JavaScript用于例如
  code？

块引用>

是的。由于上述讨论的细节，并为一种常见的做法，最JS / SPA的使用的OAuth2隐流以确保应用程序。

（为了避免混淆，请跳过此本部有这种隐含的流动几个变化。总的来说，规格的oauth2在本质上这使我们沿着的oauth2建议建行的几个混合/自定义实现流体。 OpenID的连接解决一些关切，是建立在的oauth2 的）

的顶部相对新的（成熟）规范

  

密码津贴为ASP.NET MVC应用程序 -

块引用>

密码批是指在资源所有者具有与客户强烈信任关系（例如本机应用）的情形中使用。对于这个用例，建议的交付式将授权code流量。

  

对Web API客户端凭据 -

块引用>

您是对的。客户端凭证交付式时使用的应用程序本身也是资源所有者

  

授权code为窗口服务？

块引用>

由于规格的上述原因（用户代理重定向要求等）授权code流量将不适合这里。根据Windows服务的类型，我要么使用客户端证书或密码交付式

  

能否两种类型cohesist？我如何使用标识实施apiKey
  服务器？

块引用>

我不是100％肯定在这里您的要求。但是如果你可以张贴一些有关你想达到这里。我是pretty确保布罗克/多米尼克应该能够确认。

I am trying to get my head out of the clouds with identity server.

I would like to implement the identity server project to let authenticate

1. An ASP.NET MVC 5 application
2. An ASP.NET Web API
3. A windows service implementation

Int this blog post I have read some details about clients. The author simply state:

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

What are the differences between Authorization Code and Implicit? Do this means that implicit should be used for example by javascript code?

It is right to say that I need:

1. the Password grant for ASP.NET MVC application
2. Client credentials for Web API
3. Authorization Code for the windows service?

Also another question, I would like to implement authorization in my web api based either on Bearer Token as well as a simple apiKey. Can both types cohesist? How do I implement apiKey by using Identity server?

thanks a lot and excuse me if these are stupid questions.

I tried my best to keep this answer short (But I was forced to add lot of context to make sense of the answer)

Confidential vs Public Clients

Clients (The app requesting access on your behalf – MVC App, SPA, etc.) are categorized as Confidential and Public clients based on their ability to Authenticate securely with the authorization server (in our case Identity Server).

For example, A Web Application (MVC App) is considered confidential client since it is implemented on secure server and capable of making secure client authentication with Authorization server(through back channel – without the involvement of user-agent or public channel). Also, it can maintain secret tokens (essentially client credentials, access_token and refresh token) which are protected from public access(e.g. by user-agent / resource owner)

Whereas, user-agent-based applications (SPA) and native applications (mobile apps) are considered public clients. This is because the Protocol data and client credentials are easily accessible by resource owner.

Authorization Code Grant

Oauth2 Spec Defines Authorization Code Grant as:

"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."

Which simply mean, The Authorization Code flow is optimised for a confidential client interacting with resource-owner via user-agent (browser) capable of receiving and redirecting incoming requests from Auth Server (Identity Server).

In abstract terms – Authorization Code flow has the following sequence,

• Resource-owner authenticates (via –user agent) with authorization server and obtains an authorization_code
• Resource-owner provides Authorization_code to Client (via user-agent after redirection from Authorization server)
• Client authenticates with Authorization server (via back-channel request) and exchanges Authorization_code to get access_token
• the access_token is stored in the Client and the resource-owner is redirected to the appropriate resource
• Since Client (MVC App) has the access_token, it can request for Refresh token from the authorization server (if needed).
• One important point though - In Authorization code flow Resource-owner never get to see(or have access to) Access_token. Client stores it securely.

Implicit grant

Oauth2 Spec Defines Implicit grant as:

"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?

So the main difference being:

• In Implicit grant, client does not make a separate request for authorization and access token.
• Both Authorization and access token is passed to the resource-owner, encoded into the redirect URI
• This leads to Security vulnerabilities described here https://tools.ietf.org/html/rfc6749#section-10.16
• Due to these security implications, by architecture a Refresh token won’t be issued to public clients (which are incapable of maintaining client secret, therefore Access_token and refresh token)

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

Yes. Due to the above discussed details and as a common practice, most of JS / SPA use Oauth2 implicit flow to secure the application.

(To avoid confusion, please skip this part- There are several variations with this implicit flow. Overall, Oauth2 Specifications are fluid in nature which leads us to several hybrid / custom implementations built along the lines of Oauth2 recommendations. OpenID-Connect address some of the concerns and is relative new (and mature) specification built on top of Oauth2)

the Password grant for ASP.NET MVC application –

Password grant is meant to be used in a scenario where the resource owner has a strong trust relationship with the client (such as native applications). For this use case, the recommended grant type would be Authorization code flow.

Client credentials for Web API –

You are right. Client Credentials grant type is used when the app itself is also the resource owner

Authorization Code for the windows service?

Due to the above stated reasons in spec (user-agent redirection requirement,etc) Authorization code flow won't fit in here. Depending on the type of windows service, I would either use Client Credentials or Password grant type

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

I am not 100 % sure about your requirement here. But if you could post some more details and background about what you want to achieve here . I am pretty sure Brock / Dominick should be able to confirm.