使用JWT联合身份的REST身份验证/授权

我正在考虑开发一个使用REST公开服务的应用程序。这些服务将通过浏览器和非浏览器客户端访问。我预计该软件将有许多安装，由不同的组拥有和管理。我希望使用户能够从一个系统访问另一个系统上的服务。它们不会共享同一个标识存储。我希望用户能够对其实例进行身份验证，然后使用令牌向其实例和远程实例发出请求。这似乎是JSON Web标记（JWT）的一个很好的用途。每个系统都需要配置为相互信任由证书签名的令牌

我已经读到，这可以通过使用OAuth和JWT承载令牌来实现，但这似乎比需要的开销更大。为什么要将承载令牌交换为访问令牌，而不仅仅是使用承载令牌？我质疑OAuth是否适合，因为它不是控制系统是否可以访问用户的数据，就像web上的许多示例一样，而是控制用户是否可以访问存储在系统中的数据

问题的下一部分是确定如何创建这些JWT令牌，看起来WS-Trust STS之类的东西是合适的。我还没有看到任何简单的方法，只是验证用户并返回令牌。还可以支持延长令牌的过期时间和令牌的验证，这可能很有用

在过去，我能够使用带有WS-Security和SAML断言的SOAP来启用这种类型的功能。我想看看是否可以使用REST和JWT令牌实现同样的功能。网上有很多帖子建议不要使用自己的安全框架，所以我一直有点犹豫是否继续。我看到微软增加了处理程序来保护使用JWT令牌的服务，所以他们似乎看到了这种方法的一些价值

---

是否有人对如何以符合标准且简单的方式实现REST服务的这种身份联合有见解？

是的，这是我向客户推荐的方法。事实上，JWT是WindowsAzure移动服务保护其端点的方式。JWT处理起来相对简单（例如，与SAML令牌相比），但与

access\u令牌相比，JWT保留了一些有趣的属性（比如具有签名）

显示了如何使用WebApi和我们的产品（如果您使用的是MS技术）执行此操作的示例。这些原则是通用的，无论您是否使用我们的STS，都可以应用