我花了两天时间试图了解我正在创建的网站的Amazon Cognito Access Control背后的想法。它很简单：
- 该网站允许用户创建帖子
- 任何人(匿名用户和登录用户)都应该能够看到帖子
- 只有已登录的用户才能创建帖子
- 只有原作者才能编辑自己的帖子
现在我想我已经了解了关于亚马逊cognito的事情：
- Cognito用户池用于rest接口，身份池用于创建具有特定策略的临时amazon角色，这样登录到我的服务的人就可以直接访问aws服务，如dynedb或s3 bucket
- 为了向我的rest接口发出授权请求，用户必须使用cognito UI登录并接收访问令牌，该令牌必须随每个请求一起发送到rest API以验证请求
- 验证可以使用API网关中的cognito授权器权限自动完成，也可以将访问令牌重定向到lambda并直接在那里进行验证
- 如果使用cognito authorizer完成，则无法从lambda中读取用户名和其他信息
- 如果我使用AWS Amplify在客户端处理请求授权，访问令牌将自动续订
但我对整个过程仍有一些疑问：
- Cognito用户名是否保证是唯一的？如果没有，我如何让用户在注册或使用谷歌登录后选择一个有保证的唯一用户名
- 访问令牌是否等同于会话cookie
- 如果我要在lambda脚本内部处理访问令牌，那么有没有可以使用的库或服务？因为我还没有找到验证令牌或获取与令牌关联的用户的方法
- 为什么内置的authorizer不将用户信息重定向到lambda脚本
- 是否有一个预先构建的lambda授权器，我可以直接插入API网关，允许登录用户和匿名用户向其发出请求，并将用户信息重定向到lambda脚本？因为我在存储库或其他任何地方都找不到
所以，我没有所有的答案，但我有一些答案有望指导你：
Cognito用户名是否保证是唯一的
如果已使用用户名/电子邮件，则用户无法注册。您需要指定哪个字段用于用户名(即电子邮件或用户名)
访问令牌等同于会话cookie吗？
否，访问令牌通常在请求的authorization报头内通过承载令牌策略进行通信，cookie在cookie报头内。一些服务将验证cookie，其他服务(尤其是机器对机器)将验证authorization标头。在某些情况下，开发人员可能会决定使这些功能保持不变，但并不总是这样。
如果我要在lambda脚本内部处理访问令牌，那么有没有可以使用的库或服务。
如果您希望获取访问令牌的上下文(如JWT字符串中编码的用户名)，则可以使用JWT解码函数。当请求到达lambda时，Authorizaor已经对其进行了验证，因此您不需要再次进行验证。
为什么内置的authorizer不将用户信息重定向到lambda脚本
因为并非所有服务都需要/想要它。消费服务在解码令牌后，最好对上下文执行所需操作
是否有一个预构建的lambda授权器，我可以直接插入API网关，允许登录用户和匿名用户向其发出请求，并将用户信息重定向到lambda脚本？
这个问题表明你对rest的理解有问题。API应该利用CRUD操作；因此Create可以只授予贡献者，Read可以公开授予，Update可以只授予所有者，Delete可以只授予所有人。以上只是一个概括，但您需要一个API策略；当你制定这个策略时，你会意识到没有；"容易"；按钮
一般来说，我有两个API网关，一个用于只读，另一个用于管理内容。这使它保持简单，并允许您以不同的方式进行扩展(即，在出现扩展问题的情况下，您可能希望您的贡献者不会被只读用途阻止)。
此外，采用基于路径的策略可以帮助简化谁可以获得什么资源。举下面的例子：
用户向CCD_ 8发送POST请求以创建新博客(导致CCD_。CCD_ 10端点不是"0"；拥有"；任何特定贡献者。稍后用户对/api/blog/1234-abcd进行更新。。。现在，您的服务必须进行额外的调用，以查看该资源是否为用户所有(这称为"授权"过程)。在psuedo-sql中，您将SELECT created_by FROM blogs WHERE id='1234-abcd'，然后查看created_by字段是否与您的用户id匹配。
任何人，你都明白：)如果你允许团队/多个用户修改资源，这将变得更加复杂。。。新的内容是RBAC(基于角色的访问控制)，这是一个更长的主题。
很抱歉离题了，但希望这能给你更多的指导。