IdentityServer3 - OAuth流程，不同的方法

我已经构建了一个基本上是REST Web API的应用程序。我想给其他开发者代表用户调用这些API的机会。我决定继续进行OAuth身份验证，将身份验证服务基于IdentityServer3。现在我已经成功地为使用授权流程的第三方客户端生成访问令牌。IdentityServer3 - OAuth流程，不同的方法

什么是不说服我是如何处理我的SPA，目前只使用基于cookie的身份验证（+防伪造令牌）调用我的Web API。这个应用程序用JavaScript写成，基于Backbone。实质上，它所做的只是调用我的Web API并呈现结果。我对不同的资助流程感到困惑，我不想制造安全漏洞。

解决方案，我想：

直接通过JavaScript生成令牌。我应该使用哪种流程？如何处理令牌刷新？
从后端服务器应用程序生成令牌并将生成的令牌传回给SPA（显然是通过SSL通道）。这是否安全？如果是，我应该使用哪种流程（我会说授权码流）？如何处理令牌刷新？

你会如何处理这个问题？

感谢，

马尔科

来源

2016-04-22 Marconline

下面是进入的概况的物品，其流动适合哪一种情景：https://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

来源

2016-04-22 13:15:29

谢谢！我已经偶然发现了这篇伟大的文章。如果我理解正确，正确的用法是Implict Flow，让我的Javascript SPA直接处理这个访问令牌。现在的问题是：让“浏览器”客户端直接处理令牌是不是“不安全”？谢谢。 – Marconline

取决于API。但是如果你需要JS的调用，那么你需要给JS一个令牌。也许不同的设计是让JS调用第一层API，然后调用第二层API。当然，第二个API需要自己的访问令牌，这是您要解决的下一个问题。 –

好的，谢谢。听起来像隐式流是正确的解决方案。我不会创建第二层API。谢谢 – Marconline

IdentityServer3 - OAuth流程，不同的方法

回答

相关问题