本博客是一系列教程的一部分，云服务器购买，详细解释了SAP云平台后端服务的使用。在本文中，我们将尝试对从外部应用程序调用API时所需的安全机制有一个基本的了解它就像上一篇博客的附录，在这里我们学习了从REST客户机工具调用API的步骤。我答应过没有人会成为安全专家在这个博客中，我们将尝试更好地了解我们正在做的事情但仍然不会成为安全专家。只需了解后端服务与OAuth2.0原则的关系。
在后端服务中创建的API（OData服务）受到保护，需要OAuth2.0身份验证/授权。首先：为什么是OAuth？
为什么是OAuth？
通过SAP云平台后端服务，我们正在创建一个API（OData服务）并公开它。是的，它是服务URL，而不是应用程序URL。因此，它并不意味着被人类用户直接使用最终用户希望通过用户交互（基本身份验证）打开应用程序的URL，而不是返回神秘xml或json负载的URL。因此，精准大数据，拒绝使用用户凭据直接访问API，只接受访问令牌。但是…。。是的，我知道在开发期间，经常需要手动调用服务。驾驶舱提供了一个UI，它涵盖了处理OData服务的大部分功能对于高级用法，在确实需要外部REST客户机的情况下，可以处理oauth2流，正如在一篇漂亮的博客中所解释的
OAuth通常在服务器相互通信时使用注意，当服务器相互通信时，只发送令牌。令牌的作用域有限，一段时间后就会过期，所以如果令牌被盗，它就没有密码那么重要了
好吧，理解为什么后端服务不支持基本身份验证，需要OAuth 2.0
它是什么：OAuth 2.0？
OAuth是开放授权的缩写OAuth是一个描述标准授权（和身份验证）方式的协议它被广泛应用于互联网，每当web应用程序需要从不同的服务器获取用户信息时。在这种情况下，web应用程序要求"不同的服务器"对用户进行身份验证，云服务器好还是，并允许访问用户的信息。因此web应用程序不处理敏感的用户凭据。相反，"不同的服务器"向web应用程序发送一个神秘的令牌
一个非常常见的例子是Facebook：用户打开一个web应用程序，然后将身份验证委托给Facebook服务器。web应用程序与Facebook服务器进行通信，并告诉哪些用户应该进行身份验证，哪些信息和授权是必需的。Facebook要求用户登录。如果成功，它将向web应用程序发送一个令牌。使用此令牌，允许web应用程序代表用户访问资源。好的方面是：网络应用不需要存储密码？
OAuth是web应用之间授权的标准
为什么是2.0？我们一直在谈论协议版本2.0，它与之前的版本有很大的不同。
协议是灵活的，在后端服务的情况下，大数据和云计算，它的使用方式与给定的Facebook示例略有不同。
后端服务OAuth流
让我们检查OAuth 2.0的基本原理，并将它们与安全性联系起来SAP云平台和后端服务中的机制
参与者
OAuth 2.0描述了4个参与者：
–资源服务器–授权服务器–资源所有者–Client
我们的后端服务场景：
在我们的场景中（参见本博客），在后端服务中创建了一个受保护的API。我们希望使用REST客户机工具访问API，以读取受保护的数据为了能够读取受保护的数据，REST客户端必须连接到SAP云平台中的XSUAA实例在任何情况下，都必须授予访问API的权限，因此我们必须提供SAP Cloud Platform用户的用户凭据，该用户是我们的试用帐户用户。XSUAA知道这个用户，因此XSUAA向REST客户机授予代表我们访问API的权限。为了访问API，XSUAA向REST客户端发送一个有效的访问令牌，REST客户端可以使用它来调用API。
前提条件
在授权服务器愿意向客户端发送访问令牌之前，授权服务器必须知道客户端。这是通过一次性的"注册"来实现的。
我们通过创建和配置一个XSUAA实例来实现的，如下所述在cloudfoundry空间中创建和配置XSUAA实例时，我们给出了一些参数，结果我们收到了客户机的标识符（clientid）和密码（clientsecret）。OAuth2.0规范对此进行了描述，但是，有些部分是完全免费的，并且取决于服务器和应用程序
授权
OAuth用于管理授权而不是身份验证（尽管大部分是一起使用的）。那是什么意思？通常，专业应用程序定义自己的"角色"这样，应用程序就可以允许以细粒度的方式访问部分应用程序。例如，一个应用程序的一个特殊屏幕只能由具有"Admin"角色的用户打开，而对于所有其他用户，它都不会打开。API也可以这样做。后端服务通过提供一些自己的角色来支持这一点。例如，企业服务公开有关客户及其产品的数据。虽然产品是公开可见的，但是客户数据只能由对此实体集具有特殊角色的用户访问。这就是为什么授权服务器必须知道作用域、角色和角色模板的原因（请参阅下面的xsuaa部分）换言之，访问令牌仅在包含有关所需角色的信息时有效
授权授予类型
