docker 部署 composer-rest-server踩坑版

将Google OAUTH2.0与REST服务器配合使用

本教程深入介绍如何配置OAUTH2.0身份验证策略（例如，针对Google，Facebook，Twitter身份验证提供程序等）以授权访问已配置的REST Server实例中的资源 - 并允许区块链网络的最终用户与部署智能合约/业务网络。下面显示了一个概述图，下面显示了一个更详细的图，显示了认证流程。您将以多用户模式运行REST服务器并测试与示例交易网络交互作为不同的区块链标识，通过REST API访问资源。您需要设置自己的Google帐户/授权方案才能执行此操作（请参阅有关执行此操作的步骤的附录 - 不需要很长时间），或者最低限度地使用本教程中提供的ID /元数据。可以说，它使用Hyperledger Composer作为底层区块链网络。

注意：我们按照此处描述的步骤3“设置IDE”中的说明设置了标准的“开发结构”网络

有许多Passport策略可供选择。在业务组织意义上，SAML，JSON Web令牌（JWT）或LDAP等企业策略显然更合适 - 例如组织的Active Directory服务器。我们使用/启用Google+ API作为本教程的身份验证提供程序，因为任何人都可以轻松设置Google帐户（请参阅附录了解如何实现此目的）并配置服务/执行教程，而无需担心要安装的中间件先决条件。

OAUTH2.0实际上是一种“授权协议”，但可以用作“委托身份验证方案” - 身份验证通常意味着通过自己的凭据识别用户，而此处使用的OAUTH2.0身份验证用作'委托'认证方案。这里有许多“角色”可以通过背景进行扩展。Composer REST服务器的作用是提供对受Google+ API OAuth2.0方案保护的业务网络资源的访问。资源所有者是我们设置的Google+ API用户帐户（在附录中描述），其作用是向客户端应用程序授予同意（或其他方式）。Google+授权服务器请求资源所有者的同意，并向REST客户端（例如，Web客户端应用程序）发出访问令牌，以使其能够访问受保护的资源。较小的API提供商可以在Google+中为授权服务器和资源服务器使用相同的应用程序和URL空间。这个想法是，当一个Web应用程序用户（使用REST API访问业务网络）出现时，他/她不必预先注册任何东西; 应用程序用户凭借配置的客户端应用程序被授予同意（尽管这取决于OAUTH2.0流程设置）。在我们的教程中，我们使用浏览器来使用REST API并查看此身份验证流程的实际工作方式。较小的API提供商可以在Google+中为授权服务器和资源服务器使用相同的应用程序和URL空间。这个想法是，当一个Web应用程序用户（使用REST API访问业务网络）出现时，他/她不必预先注册任何东西; 应用程序用户凭借配置的客户端应用程序被授予同意（尽管这取决于OAUTH2.0流程设置）。在我们的教程中，我们使用浏览器来使用REST API并查看此身份验证流程的实际工作方式。较小的API提供商可以在Google+中为授权服务器和资源服务器使用相同的应用程序和URL空间。这个想法是，当一个Web应用程序用户（使用REST API访问业务网络）出现时，他/她不必预先注册任何东西; 应用程序用户凭借配置的客户端应用程序被授予同意（尽管这取决于OAUTH2.0流程设置）。在我们的教程中，我们使用浏览器来使用REST API并查看此身份验证流程的实际工作方式。应用程序用户凭借配置的客户端应用程序被授予同意（尽管这取决于OAUTH2.0流程设置）。在我们的教程中，我们使用浏览器来使用REST API并查看此身份验证流程的实际工作方式。应用程序用户凭借配置的客户端应用程序被授予同意（尽管这取决于OAUTH2.0流程设置）。在我们的教程中，我们使用浏览器来使用REST API并查看此身份验证流程的实际工作方式。

访问密钥在获得同意后授予; 令牌允许客户端访问受OAuth2.0保护的API。在OAuth 2.0中，这些访问令牌称为“承载令牌”，可以单独使用，无需签名或加密，即可访问信息。此外，访问令牌存储在用户的Web浏览器的本地存储器中的cookie中。当用户发出后续请求时，将从cookie中检索访问令牌，并验证访问令牌，而不是重新验证用户。

REST服务器本身配置为使用MongoDB存储来持久保存业务网卡（连接到网络所需）。通常，组织将运行下面描述的REST服务器Docker映像的多个实例，并配置持久数据存储的高可用实例，例如MongoDB副本集。配置组件以实现高可用性允许管理员停止，重新启动或删除REST服务器实例，而无需应用程序用户通过REST失去对已部署业务网络的访问权限。

您应该以非特权用户身份执行本教程（不需要sudo或提升权限）。

步骤1：使用MongoDB设置持久数据库凭据数据存储

如上所述，一旦将适当的业务网卡导入REST钱包，我们就会将凭据存储在持久性数据存储中。

启动MongoDB实例

1. 打开终端窗口并输入以下命令：

复制

docker run -d --name mongo --network composer_default -p 27017:27017 mongo

它应输出已下载docker镜像并提供SHA256消息。已经启动了MongoDB docker容器的一个实例。使用--network composer_default此处非常重要，以便与REST服务器建立简单的网络连接。

 

步骤2：使用OAUTH2.0模块构建REST服务器Docker镜像

 

1. 在$ HOME目录中，创建一个名为dockertmpcd 的临时目录：

复制

cd $HOME ; mkdir dockertmp
cd dockertmp

1. 在临时目录中，创建一个Dockerfile在编辑器中调用的docker文件并粘贴到以下序列中（包括\下面RUN和npm下面的行后面需要的特殊反斜杠字符- 即延续字符）：

复制

FROM hyperledger/composer-rest-server
RUN npm install --production loopback-connector-mongodb passport-google-oauth2 && \
npm cache clean --force && \
ln -s node_modules .node_modules

这个Docker文件将拉出位于/ hyperledger / composer-rest-server的Docker镜像，并另外安装两个npm模块：

• loopback-connector-mongodb - 此模块为LoopBack框架提供MongoDB连接器，并允许我们的REST服务器将MongoDB用作数据源。有关更多信息，请访问：https：//www.npmjs.com/package/loopback-connector-mongodb

• passport-google-oauth2 - 此模块允许我们使用我们的REST服务器上的Google+帐户进行身份验证。有关更多信息，请访问：https：//www.npmjs.com/package/passport-google-oauth-2

1. 从Dockerfile驻留的同一目录，构建自定义Docker REST Server映像：

复制

docker build -t myorg/composer-rest-server .

给定-t标志的参数是您要为此Docker镜像指定的名称，这可以由您来命名 - 但对于本指南，该图像将被称为“myorg / composer-rest-server”。

您应该看到类似于以下内容的输出，底部的2行表示它是“成功构建”：

复制

docker build -t myorg/composer-rest-server .
Sending build context to Docker daemon  4.203GB
Step 1/2 : FROM hyperledger/composer-rest-server
 ---> e682b4374837
Step 2/2 : RUN npm install --production loopback-connector-mongodb passport-google-oauth2 &&     npm cache clean  --force &&     ln -s node_modules .node_modules
 ---> Running in 7a116240be21
npm WARN saveError ENOENT: no such file or directory, open '/home/composer/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/home/composer/package.json'
npm WARN composer No description
npm WARN composer No repository field.
npm WARN composer No README data
npm WARN composer No license field.

+ passport-google-oauth2@0.1.6
+ loopback-connector-mongodb@3.4.1
added 114 packages in 7.574s
npm WARN using --force I sure hope you know what you are doing.
 ---> a16cdea42dac
Removing intermediate container 7a116240be21
Successfully built a16cdea42dac
Successfully tagged myorg/composer-rest-server:latest

信息：不要担心如上所述在控制台上看到'npm warn messages'。这可以忽略。

1. 最后，对于本节，请在目录结构中返回一个级别：

复制

cd ..

步骤3：为REST Server实例配置定义环境变量

1. 创建一个envvars.txt在$ HOME目录中调用的文件并粘贴以下配置设置 - 请注意，您需要使用下面的自己的Google API +客户端信息替换下面显示的客户端ID和clientSecret（如附录中所示）

复制

COMPOSER_CARD=restadmin@trade-network
COMPOSER_NAMESPACES=never
COMPOSER_AUTHENTICATION=true
COMPOSER_MULTIUSER=true
COMPOSER_PROVIDERS='{
    "google": {
        "provider": "google",
        "module": "passport-google-oauth2",
        "clientID": "312039026929-t6i81ijh35ti35jdinhcodl80e87htni.apps.googleusercontent.com",
        "clientSecret": "Q4i_CqpqChCzbE-u3Wsd_tF0",
        "authPath": "/auth/google",
        "callbackURL": "/auth/google/callback",
        "scope": "https://www.googleapis.com/auth/plus.login",
        "successRedirect": "/",
        "failureRedirect": "/"
    }
}'
COMPOSER_DATASOURCES='{
    "db": {
        "name": "db",
        "connector": "mongodb",
        "host": "mongo"
    }
}'

此处定义的环境变量将表明我们希望使用Google OAuth2进行身份验证的多用户服务器以及MongoDB作为持久数据源。

第一行表示我们将启动网络的业务网卡的名称 - 针对已定义的业务网络的特定REST管理员。您还将看到，在此配置中，我们还定义了REST服务器将使用的数据源以及我们正在使用的身份验证提供程序。这些可以分别用COMPOSER_DATASOURCES和COMPOSER_PROVIDERS变量看到。

步骤4：在当前终端中加载环境变量并启动持久REST服务器实例

1. 从与envvars.txt您创建的包含环境变量的文件相同的目录中，运行以下命令：

复制

source envvars.txt

INFO没有来自命令的输出？ - 这是预料之中的。如果您的文件中确实存在语法错误，envvars.txt那么在运行此命令后，这将由错误指示。

1. 现在让我们确认环境变量确实通过使用“echo”命令检查它们中的几个来设置，如下所示

复制

echo $COMPOSER_CARD
echo $COMPOSER_PROVIDERS

步骤5：部署示例商品交易业务网络以从REST客户端进行查询

1. 如果您还没有这样做 - trade-network.bna从https://composer-playground.mybluemix.net/下载交易网络。确保记下“关于”页面上方显示的版本号。

2. 在Playground中，连接到网络admin并导出trade-network.bna并将其复制到您的主目录。

1. 要部署业务网络，首先需要将业务网络安装到对等方

复制

composer network install --card PeerAdmin@hlfv1 --archiveFile trade-network.bna

记下运行上述命令后输出的版本。这是您将用于启动业务网络的下一个命令的业务网络版本。

运行以下命令，替换<business_network_version>为上一个install命令的版本号输出。

复制

composer network start --card PeerAdmin@hlfv1 --networkName trade-network --networkVersion <business_network_version> --networkAdmin admin --networkAdminEnrollSecret adminpw --file networkadmin.card

您应该确认商品交易业务网络已经启动并且已创建“admin”networkadmin.card文件。

1. 接下来，导入业务网卡，并连接卡以将证书下载到钱包：

复制

composer card import -f networkadmin.card
composer network ping -c admin@trade-network

您应该确认连接已成功通过测试。我们现在已准备好使用已部署的业务网络。

步骤6：为Composer REST服务器实例创建REST服务器管理员

1. 创建一个名为的REST管理员标识restadmin和一个关联的业务网卡（稍后用于启动REST服务器）。

复制

composer participant add -c admin@trade-network -d '{"$class":"org.hyperledger.composer.system.NetworkAdmin", "participantId":"restadmin"}'
composer identity issue -c admin@trade-network -f restadmin.card -u restadmin -a "resource:org.hyperledger.composer.system.NetworkAdmin#restadmin"

1. 导入并测试卡：

复制

composer card import -f  restadmin.card
composer network ping -c restadmin@trade-network

1. 因为我们将REST服务器托管在具有自己的特定网络IP信息的另一个位置，所以我们需要更新connection.json - 以便docker主机名（来自持久性REST服务器实例内）可以解析彼此的IP地址。

下面的单行代码将使用docker主机名取代'localhost'地址并创建一个新的connection.json- 它将进入我们的REST管理员卡。我们还将在OAUTH2.0 REST身份验证序列中为我们的'test'身份验证用户使用此自定义connection.json文件，更接近本教程的结尾。要快速更改主机名 - 复制并粘贴，然后在$ HOME目录的命令行中运行这个单行（下面）。

复制

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/restadmin@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/restadmin@trade-network/ 

步骤7：启动持久性REST服务器实例

1. 运行以下docker命令以启动REST服务器实例（使用restadmin业务网卡）

复制

docker run \
-d \
-e COMPOSER_CARD=${COMPOSER_CARD} \
-e COMPOSER_NAMESPACES=${COMPOSER_NAMESPACES} \
-e COMPOSER_AUTHENTICATION=${COMPOSER_AUTHENTICATION} \
-e COMPOSER_MULTIUSER=${COMPOSER_MULTIUSER} \
-e COMPOSER_PROVIDERS="${COMPOSER_PROVIDERS}" \
-e COMPOSER_DATASOURCES="${COMPOSER_DATASOURCES}" \
-v ~/.composer:/home/composer/.composer \
--name rest \
--network composer_default \
-p 3000:3000 \
myorg/composer-rest-server

这将输出Docker容器的ID，例如。690f2a5f10776c15c11d9def917fc64f2a98160855a1697d53bd46985caf7934并确认REST服务器确实已启动。

1. 检查我们的容器是否正常 - 您可以使用以下命令查看它是否正在运行：

复制

docker ps |grep rest
docker logs rest

在日志末尾查找“在http：// localhost：3000 / explorer浏览您的REST API ” - 如果不存在，则返回步骤（上面）。

步骤8：测试REST API受保护并需要授权

1. 打开浏览器窗口并启动REST API资源管理器，方法是访问http：// localhost：3000 / explorer以查看和使用可用的API。

INFO管理员标识restadmin用作初始默认值 - REST服务器使用restadmin标识，直到特定标识（例如jdoe，在REST客户端钱包中设置为默认标识）。

1. 转到“系统：一般业务网络方法”部分

1. 转到“/ system / historian”API并单击“试一试！”按钮，如下所示：

您应该收到授权错误，因为我们已经配置了Google+通行证OAUTH2.0身份验证策略以保护对REST服务器的访问。一旦通过OAUTH2.0认证pa进行了认证，浏览器中的REST API就可以与Trade Commodity业务网络进行交互（即，一旦导入了名片）。

步骤9：创建一些参与者和身份以测试OAUTH2.0身份验证

1. 您需要创建一个集合参与者和身份，以便进行测试，以便与业务网络进行交互。这是因为REST服务器可以在多用户模式下处理多个REST客户端。我们将使用composer CLI命令添加参与者和身份，如下所示 - 名字是Jo Doe：

复制

composer participant add -c admin@trade-network -d '{"$class":"org.example.trading.Trader","tradeId":"trader1", "firstName":"Jo","lastName":"Doe"}'
composer identity issue -c admin@trade-network -f jdoe.card -u jdoe -a "resource:org.example.trading.Trader#trader1"
composer card import -f jdoe.card

1. 再一次，因为我们将使用此标识在持久性REST docker容器内进行测试 - 我们需要更改主机名以表示docker可解析的主机名 - 再次运行此单行程序以快速执行这些更改：

复制

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/jdoe@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/jdoe@trade-network/ 

1. 我们需要将卡导出到文件 - 用于导入其他地方 - 即我们将用于导入我们浏览器客户端钱包的卡 - 因此，此时，我们可以丢弃初始业务网卡文件jdoe。

复制

composer card export -f jdoe_exp.card -c jdoe@trade-network ; rm jdoe.card

1. 对参与者Ken Coe（kcoe）重复上述步骤- 创建trader2参与者并发出身份kcoe- 命令序列为：

复制

composer participant add -c admin@trade-network -d '{"$class":"org.example.trading.Trader","tradeId":"trader2", "firstName":"Ken","lastName":"Coe"}'
composer identity issue -c admin@trade-network -f kcoe.card -u kcoe -a "resource:org.example.trading.Trader#trader2"
composer card import -f kcoe.card

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/kcoe@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/kcoe@trade-network/ 

composer card export -f kcoe_exp.card -c kcoe@trade-network ; rm kcoe.card

现在可以导入这些卡，然后在下一节中将其用于REST客户端（即浏览器）。

步骤10：从REST API Explorer进行身份验证并使用特定身份进行测试

1. 转到http：// localhost：3000 / auth / google - 这将引导您进入Google身份验证同意屏幕。

1. 使用以下凭据登录:(示例如下所示 - 建议您按照本教程附录部分中的说明进行设置）：

• 电子邮件：composeruser01@gmail.com

• 密码：

1. 您将通过Google进行身份验证，并重定向回REST服务器（http：// localhost：3000 / explorer），该服务器在左上角显示访问令牌消息 - 单击“显示”以查看令牌。

虽然我们的REST服务器已通过Google+ OAUTH2.0服务进行身份验证（由其项目/客户端范围定义，并使用附录中为我们的OAUTH2.0服务设置的客户端凭据），但我们还没有真正做过任何事情。区块链身份或使用商业网卡与我们的Trade Commodity业务网络进行交互 - 接下来，我们将使用jdoe我们之前创建的身份进行交互。

步骤11：检查默认钱包并导入卡并设置默认身份

1. 首先，转到Wallets下的REST端点并进行GET操作（和'试一试'）以获取钱包的内容 - 检查钱包是否包含任何商业网卡 - 它应显示为空[ ]：

   GET /钱包

2. 您需要向REST客户端钱包添加标识，然后将此标识设置为用于进行API调用的默认标识。转到/ Wallets下的POST系统操作 - 它称为/Wallets/Import端点

3. 选择导入文件jdoe_exp.card - 并将卡的名称提供为jdoe @ trade-network，然后单击“试一试”

1. 向下滚动 - 您应该获得HTTP状态代码204（请求成功）

2. 接下来，回到

   GET /钱包

您应该看到它jdoe@trade-network已导入钱包。另请注意，该值为default propertytrue，这意味着在与商品交易业务网络交互时，默认情况下将使用此业务网卡（直到您将其更改为使用其他网络卡为止）。

步骤12：测试与业务网络的交互作为默认ID jdoe

1. 转到“系统REST API方法”部分，然后展开/ GET System / Historian部分

1. 点击“试一试” - 你现在应该看到来自Historian Registry的结果，作为区块链标识'jdoe'和一组交易

1. 转到Trader方法并展开/ GET Trader端点，然后单击“试一试”

它应该确认我们能够像jdoe在经过身份验证的会话中一样与REST服务器进行交互。

您现在应该能够看到当前创建的所有交易者参与者。如果已设置任何ACL，则可以应用对其可以看到的限制（它们尚未应用于此当前示例网络，但ACL规则的示例可在ACL教程 FYI中看到）。可以说，访问业务网络的REST API受访问控制 - 就像与业务网络的任何其他交互一样（例如Playground，JS API，CLI等）。

1. 接下来，返回POST /wallet/import操作并导入kcoe_exp.card卡名称设置为的卡片文件，kcoe@trade-network然后单击“ Try it Out导入它 - 它应该返回一个成功的（204）响应。

1. 但是，要使用此卡，我们需要将其设置为电子钱包中的默认卡名称 - 转到POST /wallet/name/setDefault/方法并选择kcoe@trade-network默认卡名称并单击Try it Out。这是现在的默认卡。

1. 返回Trader方法并展开/ GET Trader端点，然后单击“试一试”。它应该确认我们现在使用不同的卡名称，并且仍然能够与REST服务器进行交互，因为我们仍然需要进行身份验证。

结论

本教程部分到此结束 - 您已经了解了如何配置基于客户端的Google OAUTH2.0身份验证服务，该服务可用于授权客户端应用程序并同意与受保护资源服务器（即REST服务器实例）进行交互，而无需需要对每个请求进行身份验证。此外，REST服务器以多用户模式运行，因此，允许多个区块链标识与来自同一REST客户端会话的已部署的商品交易业务网络进行交互，受令牌到期时间等因素影响。

下面的附录介绍了如何在本教程之前设置本教程中的Google身份验证方案。

附录 - Google+身份验证配置和设置

下面的附录介绍了如何创建OAUTH2.0身份验证服务以验证客户端应用程序。高级概述中的这些步骤包括：

1. 创建Google API +项目

2. 创建凭证服务帐户

3. 创建OAuth2.0同意

4. 为凭据服务帐户创建OAuth2.0客户端ID凭据

第A1步：创建Google API +项目

1. 登录您的Google帐户 - 如果您还没有 - 请在google.com上创建一个并登录Google

2. 该页面的链接https://console.developers.google.com/apis/

您应该在抵达时看到以下页面。在搜索栏中搜索“Google+”，然后在显示时选择Google+ API图标。

1. 选择后 - 点击启用Google+ API - 执行此操作非常重要。

2. 由于您还没有“项目”，系统将提示您创建项目，因为它需要启用API。点击“创建项目”

3. 系统会提示您为其命名 - 称之为“GoogleAuth”，并在我们的案例中记下项目ID，proven-caster-195417这将在稍后使用。

4. 创建项目后，您将再次被重定向到Google+ API页面。您现在应该看到选中的项目名称和“启用”服务的选项。点击“启用”。

步骤A2：创建凭证服务帐户

1. 启用该服务后，系统将提示您创建服务帐户凭据，以便您可以使用该服务。单击“创建凭据”。

2. 系统会询问您一系列问题，以确定您需要哪种凭据。给出下面屏幕截图中显示的答案。为API，Web服务器（例如Node js，Tomcat）和应用程序数据选择“Google+ API”，在底部为引擎问题选择“否”。

3. 单击What credentials do I need 并单击继续

1. 接下来，设置一个凭据服务帐户 - 名称为“GoogleAuthService” - 在下拉列表中选择“项目”，然后选择一个角色Owner和一种类型的JSON和

2. 单击“获取凭据” - 它应以JSON格式下载（或提示下载）服务凭据 - 将这些凭据保存到安全位置。

1. 使用应用程序凭据保存JSON文件。下载凭据后，该站点将带您返回凭据主页，您将看到一个新的服务帐户密钥。

步骤A3：创建OAUTH2.0同意

1. 转到“OAuth同意屏幕”标签=您需要提供“Google Auth REST OAUTH2服务”等“产品名称” - 请求同意授权请求时显示的横幅（即我们在主教程中的REST客户端）和电子邮件地址，单击“保存”。

OAuth同意屏幕是用户（在教程中）在针对Google Auth REST服务进行身份验证时将看到的内容

步骤A4：为凭据服务帐户创建OAuth2.0客户端ID凭据

1. 返回“凭据”标签，然后点击“创建凭据”下拉列表，然后选择“OAuth客户端ID”。

2. 选择“Web应用程序”并为其指定一个简单的名称，如“Web Client 1”

3. 在“授权的Javascript起源”部分下添加一行包含以下URI - 这是客户端应用程序（REST服务器）：

   HTTP：//本地主机：3000

4. 我们需要在底部添加“授权重定向URI” - 这是经过身份验证的会话在获得Google+ OAUTH2.0身份验证服务的同意后重定向回的位置。回调将匹配我们将在Composer REST Server环境变量中配置的内容（特别是变量COMPOSER_PROVIDERS，在envvars.txt主教程中执行此指令时）。

在“授权重定向URI”下，将以下URI添加为授权URI。注意：最好复制/粘贴下面的每个URI，然后在每行输入后在浏览器中按Enter键 - 因为URI行编辑器有时会在键入.eg时截断您的条目，如果您在键入URI时碰巧暂停。

复制

http://localhost:3000/auth/google
http://localhost:3000/auth/google/callback

然后单击底部的“创建”按钮。

系统将提示您保存客户端ID和客户端密钥 - 复制这两个并保存这些以供日后使用。

您已完成设置 - 您现在可以使用Google的OAUTH2.0客户端身份验证服务返回主教程以设置REST服务器身份验证。

关于Google身份验证OAUTH2.0设置和身份验证范围的一句话

当应用程序使用OAuth 2.0进行授权时，它会代表用户请求访问资源的OAuth 2.0访问令牌，该资源由一个或多个范围字符串标识。通常，当然 - 要求用户自己批准访问权限。

当用户（例如，管理员）授予对特定范围的应用的访问权限时，至少在Google中，在Google+ API控制台中设置项目级同意“品牌”以质询初始同意。此后，一旦同意，Google会认为用户（通过他/她设置的Google帐户）已授予对API +项目中任何已配置客户端ID的特定范围的访问权限; 该授权表示对整个应用程序的信任 - 对于Google+ API配置中定义的范围。

结果是，不会提示应用程序提供程序为同一逻辑客户端应用程序多次批准对任何资源的访问。

幸运的是，在评估是否授权同一项目中的其他人时，Google授权基础架构可以在Google+ API控制台中设置的给定项目中使用有关客户ID的用户批准信息。它还要求您设置可以授予同意的授权URI（例如成功验证后的应用程序回调URL）。

Google授权模块将观察到调用应用程序和Web客户端ID位于同一项目中，未经用户批准，将ID令牌返回给Google签名的应用程序。ID令牌将包含多个数据字段，其中以下特别相关：

复制

iss: always accounts.google.com

aud: the client ID and secret of the web component of the project

email: the email that identifies the user requesting the token

此ID令牌旨在通过HTTPS传输。在使用它之前，Web组件必须执行以下操作：

验证加密签名。因为令牌采用JSON Web令牌或JWT的形式，并且存在用于验证大多数流行编程语言中可用的JWT的库，这是直截了当且高效的。

确保该aud字段的值与其自己的客户端ID相同。

完成此操作后，REST服务器可以高度确定 - 令牌由Google发出。