这篇文章的目的是概述认证和SSO的关注点是如何结合到授权中去的（主要是在API授权的范围内）。应用架构利用行业标准的协议和模式，在所有的应用中一起工作，如B2C、B2B和B2E。本文档的主要读者是应用架构师和应用安全架构师。然而，那些在 身份和访问管理领域的人也会发现这里的概念适用于他们。
网络应用和移动厚客户端认证策略
所有应用领域（B2C、B2B和B2E）的网络应用（包括移动和非移动）的用户认证和授权应该集中在SSO（单点登录）上。网络应用使用支持SAML2和OAuth2等标准的身份提供者对用户进行认证。此外，所有移动（手机或平板电脑）厚重的应用程序应该利用支持行业标准OAuth2协议的身份提供者来认证他们的用户。
JWT - JSON网络令牌
JSON Web Token（JWT）是一种javascript对象符号，是HTTP授权头和查询参数的表示格式。JSON与JSON Web签名（JWS）结构一起被用于Rest API的有效载荷中，或者作为JSON Web加密（JWE）结构的明文，以使索赔数字化。JWT总是使用JWS/JWE紧凑序列化表示。JWT的工作原理是对一个由小型JSON对象组成的字符串进行简单编码，并使用双方共享的秘密对其进行散列。该算法是可配置的，但通常是HMAC SHA-256。JWT不对有效载荷进行加密，它只对其进行签名。
网络应用程序认证和SSO
基于行业标准的Web应用认证和SSO方法围绕两个协议：
- SAML 2.0
- OAuth2
OAuth2协议最初被大型社交网站（Facebook、Google、Twitter等）广泛采用，用于认证，因为他们采用了OAuth2并创建了专有的SSO机制。因此，用户在使用他们的API时，经过认证后可以在他们的应用程序之间来回穿梭。虽然SAML 2.0在旧的应用中享有广泛的采用，用于认证REST/JSON超过了SOAP/XML。如今，所有的应用程序都采用OAuth2作为标准。
OAuth 2访问令牌
RESTful APIs使用OAuth2来保证安全；希望调用者能提供一个OAuth2访问令牌。调用者提供的访问令牌应该只作为授权HTTP头传递，如
- 授权。Beareraccess_token
客户端通过HTTPS/SSL与RESTful APIs交互，HTTP头的内容以及访问令牌都是加密的。因此，通过下面这样的查询参数传递OAuth2访问令牌是被禁止的标准，因为必须保密的访问令牌会在传输过程中暴露，并出现在Web服务器日志中：
- https://<>/profile? access_token=MzJmNDc3M2VjMmQzN
所以，关键的一点是，客户必须获得OAuth2访问令牌，以便与RESTful APIs进行交互。获得令牌的方式有几种，取决于应用程序的类型、涉及的授权源、是否采用了SSO方式等。所有这些方法都需要与OAuth2授权服务器通信。必须了解的是，OAuth2框架并不提供SSO。
OAuth2中的角色
- 资源所有者- 这是使用应用程序的用户，拥有/有权利访问资源服务器提供的数据。他们授权客户端应用程序访问后端数据。
- 资源服务器- 暴露RESTful APIs的服务器。
- 客户应用 - 请求访问资源服务器的应用。它可以是一个传统的Web应用程序，一个JavaScript（单页应用程序或SPA）应用程序，或一个移动应用程序。
- 授权服务器- 服务器向客户发出访问令牌。客户端使用这些令牌来请求对资源服务器的访问。
OAuth2 REST API访问
网络应用程序需要访问RESTful API，而网络应用程序已经拥有一个访问令牌，在用户认证时与JSON网络令牌（JWT）一起交付。由于OAuth2要求认证提供一个访问令牌，而应用程序由于用户认证已经拥有了访问令牌，因此两者使用这种模式结合起来。这适用于所有的网络应用，在这些应用中，两者都使用，并且用户已经登录了。兼容OAuth2的授权服务器在OAuth2.0令牌验证端点返回一个带有用户要求的JWT。兼容OAuth2 Connect的身份服务器返回一个包含用户声明的JWT。兼容OAuth2的授权服务器可以返回一个JWT或JSON作为用户信息端点响应。
对于所有的REST API来说，向安全的SSL和TLS通道公开总是一个好主意。最后，OAuth2是微服务架构中广泛使用的Rest API的认证，使用JWT令牌机制。
