我已经在FileMaker中构建了一个Room Booking应用程序，该应用程序可以通过经过OAuth2认证的Calendar API访问Google Calendar。
除了我不确定OAuth2客户端令牌流与将使用该系统的单个FileMaker / GCal用户之间的关系之外，所有其他方法都运行良好。
目前，我既是Google开发者控制台中项目的所有者，也是唯一的Beta测试人员，因此该系统自然可以与我的日历一起使用-我登录一次，将OAuth2的ClientID和Secret传递给OAuth2，生成我的日历代码，将其交换为令牌并刷新，然后退出。
但是，目前整个系统只有一个令牌和刷新，它们保存在单个行的FileMaker表中，因此，当我创建第二个测试用户时，事情仍然会转发到我的日历中。
这是我不清楚的地方。听起来很明显，但是很难找到一个明确的答案。
是否应该让每个用户使用相同的ClientID和Secret（我对他们保密）来生成自己独特的令牌集？
单个集是否足够，我误解了系统的其他方面（如果是，那是什么）？
简而言之：令牌是每个应用程序还是每个应用程序用户？
答案 0 :(得分：0)
回答我自己的问题：
客户ID ：与该应用程序有关，适用于所有用户
客户机密：与该应用程序有关，对所有用户通用
重定向URI ：与该应用程序有关，适用于所有用户
授权代码：特定于每个用户，需要客户端ID和客户端密钥，并在用户通过第三方服务（例如{{3}）进行身份验证后从重定向URL中作为GET变量进行检索。 }）
刷新令牌：特定于每个用户，需要客户端ID和授权代码
访问令牌：特定于每个用户，需要客户端ID和刷新令牌，并且受时间限制（通常为1小时），因此一旦过期，则需要重新生成一个新令牌。
NB用户不应看到客户端密钥（或者最好是客户端ID）。应该在应用程序的内部逻辑中使用它们，以生成对用户代码/令牌的调用，但看不到它们。
因此，从本质上讲，OAuth2“流”如下：
1）您的客户ID +客户机密+他们对第三方服务的身份验证登录名=该特定用户的身份验证代码为重定向URI中的GET var
2）您的客户ID +您的客户机密+他们的验证码=刷新令牌和访问令牌
3）您的客户ID +您的客户机密+他们的刷新令牌=新的访问令牌