我的任务是为客户创建面向服务的生态系统 . 整个过程将基于REST并在ASP.NET中构建，但我的问题是与技术无关 . 我们希望拥有一个集中式身份验证服务，该服务可以发布JWT令牌以及受环境中其他服务信任的声明 .
我的问题是这个 - Web客户端（浏览器）要求的第一件事是什么？我见过的所有图表（我将尝试添加几个示例链接）使得客户端需要自我意识并意识到他们在创建第一个之前需要一个令牌请求功能REST服务，这对我来说似乎很好 .
我希望它工作的方式是他们只是尝试访问安全资源，但是没有auth令牌，请求我的REST服务挑战他们的用户/密码，但随后将身份验证委托给我的身份验证服务 . 所以：
-
浏览器请求REST服务上的受限资源
-
REST服务返回401
-
浏览器收集凭据，发送到同一Web服务
-
REST服务连接到身份验证服务，从客户端请求传递Auth标头
-
Auth服务创建JWT令牌并将其返回给REST服务
-
REST服务验证JWT并用JWT令牌替换Auth头
-
JWT令牌为后续请求保留，直至expy设置
......我完全不喜欢这个吗？ Web客户端是否需要知道有一个单独的auth服务并在那里发出一个请求来获取他们的JWT，然后第二个请求REST资源通过JWT？这对我来说似乎很笨拙，我希望这不是主意 .
此外，另一个n00b问题 - 是由Web客户端自动保存的JWT令牌，并随每个请求重新发送，因此我不必每次都要经过身份验证服务步骤吗？这是到期设置的用途吗？
TIA .
请参见图1，了解我的意思：http://msdn.microsoft.com/en-us/library/hh446531.aspx
1 回答
从您的上一个问题开始，将使其余答案更清晰：
"...is the JWT token automagically kept by the web clients and re-sent with every request.." - 想法是发布JWT一次，将其发送到客户端，以便客户端可以保存它并在每个后续请求中发送它 . 这样，您的前端应用程序将只发送一次用户名和密码，然后使用JWT进行身份验证 . 您必须使用浏览器存储（本地或会话）或cookie（旧版浏览器的常见后备）存储JWT .
"...Does the web client need to know that there's a separate auth service involved..." - 您需要将用户名和密码发送给服务才能发布JWT . 您只需一个请求即可实现它，但您需要向服务发送凭据（由用户提供），接收JWT作为响应的一部分并存储它（如上所述） . 根据需求和实现，在单独的请求上执行此操作可能更容易 .