iOS – AWS MobileHub使用开发人员身份validation的提供程序进行login

我试图了解如何使用AWS mobilehub的iOS SDK使用开发人员身份validation的身份进行loginAWS更改了此SDK，我找不到任何文档。 示例应用程序未能揭示这一点。

我有一个REST API来检索authenticationID和令牌，但我不知道如何处理他们，一旦我有这个。

AWS有以下不同的类别，这些问题更加复杂：

AWSCredentialsProvider，AWSCognitoCredentialsProvider（不再在新SDK中可用），AWSSignInProvider，AWSAbstractCognitoIdentityProvider（在新的SDK中不再可用）

现在有一些叫做AWSAbstractCognitoIdentityProviderHelper的东西。

这些由AWSIdentityManager处理，它是AWSMobileHubHelper.framework的一部分，但AWSIdentityManager不允许您设置凭证提供程序，所以我不明白我在这方面是如何与之交互的。

任何教程，文档等将不胜感激

Answer 1

您的问题暴露了某些术语问题：

• 当你说开发者时，我不确定你的意思是与AWS意味着什么。
  • AWS使用术语“开发人员”（如“开发人员身份”）来表示
    外部维护池，而不是私人维护。 AWS拥​​有自己的产品（Cognito用户池），您可以将其私人维护为AWS服务。 AWS不认为用户池是开发者身份提供者（但在实践中，它只是完全实现了开发者身份提供者的重命名版本）。
• 关于维护令牌
  • IOS SDK维护您访问AWSServices所需的令牌。 你应该使用Mobile Hub，（它比SDK有更好的对象和接口devise）。 但是无论您是直接使用移动​​中心帮助程序还是使用SDK，都不必pipe理令牌（SDK可以帮您实现）。 文档（几乎是残酷的）掩盖了这个事实（是的，它落后于SDK）。

3种使用Cognito的方法

你必须明白，有3个不同的接口apis。

1. COGNITO API和最新的 API文档（RESTFUL交互）
2. ISO SDK和过时的 SDK文档（SDK不是RESTFUL，它有很多状态）。
3. 移动集线器助手（MHH）SDK – MHH由集线器进行了文档logging（稍微），用于生成appledoc文档的.h文件也非常好。

关于身份和login/authentication（这个问题的主题）aws-mobile-hub-helper（以下简称MHH）devise优雅，运行良好。 我会build议任何人使用Cognito开始与移动中心网站（或至less与aws-mobile-hub-helper）。 MHH基本上是SDK的一个包装，有助于澄清和分离AWS服务的持续联合身份和凭证/授权问题，以解决身份，身份validation和属性/声明等问题 。

• MHH中的身份只有一个类AWSIdentityManager 。
• 在MHH login有一个协议， AWSSignInProvider ，和该协议的两个实现（加一个我做的）：
  1. AWSGoogleSignInProvider ：针对Google+的AWSSignInProvider的OpenID-Connect / OAuth实现
  2. AWSFacebookSignInProvider ：面向Facebook的AWSSignInProvider的OAuth / Proprietary实现
  3. AWSCUPIdPSignInProvider ：适用于Amazon AWS的AWSSignInProvider的OpenID-Connect / OAuth实现Cognito您的用户池服务（可在分支存储库中使用）

Mobile-Hub-Helper只logging在.h文件中。 这些可以通过appledocs处理成文档，如果你有一个类结构的概述（不存在，但我会尝试提供），那么这些注释就相当不错了。

SDKauthenticationstream程

AWSlogging的身份validationstream程过于简单化，无助于理解如何使用SDK和Mobile Hub Helper完成身份validation。 下图试图传达如何使用AWS服务（如S3和DynamoDB）进行身份validation（login）和授权（凭证）。

理解Cognito

• 理解Cognito最初是混淆了各种各样的
  理由：a。身份authentication，授权和身份pipe理
  分布式系统是复杂的。 有许多不同angular色的派对，精心制定与钥匙，代币和钥匙的交互
  签名。 最终用户，依赖方（RP）的身份
  提供者（IdP）正在使用的资源（RS）和资源所有者
  （RO）。 这个术语由OpenId Connect和OAuth2.0使用
  标准文件。 由于原因将变得清楚，这一点
  术语不被AWS一贯使用。 但他们的概念和
  当使用Cognito时，实体都在那里。
  • 在线有一些很好的OpenID连接概述（例如： http ： //nordicapis.com/api-security-oauth-openid-connect-depth/ ），对这些概述有帮助。
• Cognito允许非OpenID连接身份提供商，这是一个优势（例如：允许OAuth /专有Facebook身份API），但这也意味着Cognito正在播放“联合”
  angular色。 这个angular色超出了OpenID Connect标准的范围
  文档（更新1：最近我开始怀疑Cognito凭证提供程序是否真的是RP（依赖方），然后为AWS服务颁发证书，但是这里的要点是OpenId Connect没有规定来自不同身份IdP可以合并），亚马逊本质上是发明了这个angular色，这样做有一些命名上的挑战。

Cognito命名

• Cognito是由AWS创build的单一名称，涵盖许多function和angular色。

  1. 有Cognit的RESTFUL web API，但也有
     Cognito SDK。 SDK调用和API消息不被命名为
     相同，SDK调用会进行多个API调用。
  2. Cognito可以联合身份提供者。 它可以坚持和
     不同身份authentication的用户之间的关联
     提供者（所以它可以记住你的谷歌+和你的脸书
     身份并将其与一个Cognito身份标识相关联。）
  3. Cognito可以为用户以及经过validation的用户提供持久标识Id（如果匿名，则使用Keychain数据来跟踪IOS设备）。 这些存储在所谓的身份池（不要与用户池混淆）。 您的应用程序会为不同设备上的用户收到相同的身份标识，以供已authentication的用户使用。 未经身份validation的（来宾）身份标识符遵循单个设备。
  4. Cognito可以存储（称为“同步”）状态数据IdentityId（在AWS服务器上），该数据用于已authentication和未authentication的用户。
  5. Cognito有一个AWSCredentialsProvider（AW​​S Credentials的来源，用于使用AWS服务（Cognito，也包括S3，DynamoDB等）
  6. Cognito可以创build一个名为“用户池”的OpenID Connect服务器，Cognit Identity可以使用该服务器对用户进行身份validation。
  7. Cognito是新的，但是AWS联合身份validation和AWS身份pipe理和AWS证书不是，所以有许多职责交叉重叠。 而命名约定混乱（考虑名称AWSCognitoIdentityCognitoIdentityProvider！）。 userpools的“cognito”品牌名称的使用，实在是一场噩梦。 一个AWSCognitoIdentity是Cognito Federated Identity CFI，但是一个AWSCognitoIdentityProvider是一个类似userpools的身份validation提供程序，也称为身份提供者。

• SDK类名称很混乱。 但除less数例外，以AWSCognitoIdentity （但不是AWSCognitoIdentityProvider）开头的类是关于credentialsProvider / IdentityProvider的，以AWSCognitoIdentityProvider开头的类与Oauth / Open Id Connect提供者和其他分布式身份提供者（facebook）相关。

词汇/同义词

这些术语在整个AWS文档和营销材料中使用松散。 这是试图通过将AWS交换使用的术语进行分组来整理术语。

• 身份提供者，身份validation提供者，login提供者，联合身份提供者
• 亚马逊Cognito，Cognito证书提供者，认知标识（似乎都指同一个类/过程）
• Cognito用户池，Cognito您的用户池，用户池。 银联是身份提供商又名authentication提供商
• Cognito身份池，游泳池，认知池，身份池。 有时候被称为身份提供者（这似乎是不正确的），但它永远不会被称为身份validation提供者
• 开发人员身份，开发人员身份validation身份，开发者提供者，开发人员身份提供者，所有这些都是用来指私人外部身份提供者。
• 身份是Cognito文档中经常被滥用的术语。 了解Cognitopipe理的身份有两种不同的types是非常重要的。 identityId （应该是小写）是Cognito与凭证相关联并用于联合不同身份提供者的持久唯一名称，以及身份提供者身份标识（大写）。
• identityId标识ID，id（如在get-id中），标识，identityId
• 身分
• 联邦意味着多种事物。
• Web联合身份validation – 联合身份validation的一种较早的方式
• Cognito联合身份
• BYOI（带自己的身份）通常通过OpenId-Connect用户可以使用谷歌，脸谱或其他身份提供者（也许是开发者提供的身份）。

IdentityId行为

• 身份证号码如下所示：us-east-1：982396fs-841e-3cdd-9r43-e7ac41bhbcb28
• 身份标识保存在钥匙串条目中的IOS设备上。 对于未经身份validation的IdentityId，它将保持不变，直到您清除钥匙串（这可以通过模拟器在Simulator – > Reset Content and Settings …中进行）。 此时，IdentityId被放弃。 它没有被禁用，它只是从来没有再次使用。

• 当用户进行身份validation时，身份validation会禁用未经身份validation的身份标识（身份标识将在IdentityPool条目中的login数组中标记为DISABLED，您可以在Cognito控制台中看到这一点）。 有一个例外：如果这是身份validation第一次发生此身份然后未经身份validation身份Id不放弃，但与身份关联，并将用作身份validationID前进。

• 合并来自不同身份提供者的多个身份（意味着用户名不是IdentityId），放弃（禁用）其中一个身份ID，并将两个身份与另一身份ID相关联。 禁用Id的创build，每当发生这种情况。 这些放弃的identityId在authentication标识池中的Logins数组中标有DISABLED。

• 在实践中，这个过程创build了一个合理的唯一身份ID使用的残疾人只有当用户在一个新的设备进行身份validation时创build（这可能是麻烦的testing，因为它创build一个残疾人和未使用的身份ID的testing当testing人员注销和多与多个id的时间）。 但在实践中，常见的使用案例不会产生这种残疾身份标识的障碍。 用户会：

• 连接 – 获取未经身份validation的身份validation – 并使用相同的ID。 没有被遗弃的id被创build。

• 连接另一台设备 – 在这里他/她会暂时得到一个新的未经身份validation的身份证 – 当他/她通过身份validation并获得身份标识符时，未经身份validation的身份证将被禁用和放弃。
• 每个来自两个身份提供者的身份合并也将创build一个残疾和被遗弃的身份ID。

AWSIdentityProviderManager

• AWSIdentityProviderManager是pipe理联合AWSIdentityProviders的协议

• 在mobile-hub-helper中，AWSIdentityManager是AWSIdentityProviderManager

  • 它所需要做的就是返回凭证提供者login字典，提供者名称和ID令牌。 AWSIdentityManager仅返回单个身份提供者的提供者名称和令牌。 它只是从AWSSignInProvider获取名称和标记并返回。 （有一个修改后的fork ，可以在login字典中返回所有当前login的提供者。）

  • 修改后的AWSIdentityManager维护一个名为cachedLogins的NSDictionary。 每个新的login都会将一个login名（身份提供者名称和id令牌）添加到caching中。 然后login总是返回整个loginCache。 这是什么支持身份合并。

• 当证书提供者调用它的关联AWSIdentityProviderManager的login方法，并find一个login列表而不是一个，它将合并身份标识符的数据库中的login，并禁用其身份标识其中之一。 它如何知道哪个ID与哪个login？ ID令牌包含一个可编码的可解密（将令牌粘贴到https://jwt.io中以查看）一组索赔，其中一个是身份（例如：用户名）

• 注意：即使您的身份标识具有多个相关的login名，在Mobile Hub Helper中，您也只能通过一个AWSSignInProvider进行身份validation。 凭证与合并的identityId相关联，但是在移动集线器帮助器中，对身份标识的访问始终通过活动的AWSSignInProvider（身份validation提供程序）进行访问，即使您使用多个身份提供程序login也是如此。 您的应用程序可以跟踪所有AWSSignInProviders并独立于AWSIdentityManager访问它们，但是从AWSIdentityManagers的angular度来看，您是使用其中一个login的。 在实践中，这个影响不大（直到你试图从不同的提供者那里得到诸如imageURL之类的“声明”）。

关于合并身份

• 目前AWSIdentityManager不支持身份合并。 我有一个分叉的存储库https://github.com/BruceBuckland/aws-mobilehub-helper-ios从github存储库中添加该function，并添加Cognito用户池标识提供程序AWSSignInProvider（AW​​SCUPIdPSignInProvider.swift）。

• 在合并身份的时候，你可能会想到各种各样的问题。

• 如果我试图合并来自同一个提供者的两个身份（如果我不是字典键是不一样的话）？

• 如果我尝试合并两个身份，每个身份都与来自与其相关的同一个提供者的身份不同（再次，他们将创build两个具有相同密钥的实体）。

• Cognitopipe理这个美丽，并拒绝尝试合并
  身份不能合并。 拒绝发生在login时（当您尝试获取凭据时，凭据提供程序将拒绝包含不可合并的identityId的login字典）

Cognito埋藏其数据

• Cognito在设备上存储包含最后使用的identityId的钥匙串。 在调用credentialProvider.credentials（IOS SDK名称）时，credentialsProvider / identityProvider对象将使用此凭据重新使用现有的身份（例如，未经身份validation的身份），并避免创build未使用的身份，除非用户确实不会login或恢复。

• Mobile-Hub-Helper的AWSSignInProvider和AWSIdentityManager在NSUserDefaults中存储一个打开会话状态的指示。 这些是用来重新启动会话，如果应用程序被终止并重新启动。

• AWSSignInProvider也存储NSUserDefaults，有时在IOS Keychain中用于内部目的（比如保留对用户名或者imageURL或令牌的简单持久访问）