你的问题暴露某些术语问题：

Your question exposes certain terminology problems:

• 当你说 开发者 时，我不确定你意味着AWS
  的意思相同。
  
  
  
  
  • AWS使用术语开发人员（如开发人员身份中）表示外部维护池的
    而非私人维护。 AWS
    拥有自己的产品（Cognito用户池），您可以将其私有
    维护为AWS服务。 AWS不认为用户池是
    开发者身份提供者（但实际上，它只是一个完全实现的重命名版本的开发者身份提供者）。
  
  
  
  
  • IOS SDK维护访问AWSServices所需的令牌。
    您应该使用Mobile Hub（它有比SDK更好的对象和
    接口设计）。但无论您是使用
    mobile-hub-helper还是直接使用SDK，您都无需管理
    令牌（SDK会为您执行此操作）。文档（几乎是残酷的）掩盖了这个事实（是的，它落后于SDK）。
  
  

  3种使用Cognito的方法

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

  You must understand that there are 3 different interface apis.

  
  
  1. COGNITO API和最新 API文档（RESTFUL交互）
  
  
  2. ISO SDK和过时 SDK文档（SDK不是RESTFUL，它有（b）移动中心帮助程序（MHH）SDK - 集线器记录了MHH（一点点），用于生成appledoc文档的.h文件也很好。
  
  
  1. COGNITO API and up to date API documentation (the RESTFUL interaction)
  2. ISO SDK and out of date SDK documentation (the SDK is not RESTFUL, it has ton's of state).
  3. Mobile Hub Helper (MHH) SDK - MHH is documented (a little) by the hub, and pretty well in the .h files used to produce appledoc documentation.

  关于身份和登录/身份验证（此问题的主题），aws-mobile-hub-helper（以下简称MHH）有一个优雅的设计，效果很好。我建议使用Cognito的任何人从Mobile Hub站点开始（或者至少使用aws-mobile-hub-helper）。 MHH基本上是SDK的包装器，有助于澄清和分离 的问题 持久联合身份和AWS服务的凭据/授权 的问题身份，身份验证和该身份的属性/声明 。

  With respect to Identity and SignIn/Authentication (the topics of this question) aws-mobile-hub-helper (hereafter MHH) has an elegant design and works well. I would recommend anyone using Cognito start with the Mobile Hub site (or at least with aws-mobile-hub-helper). The MHH is basically a wrapper to the SDK and helps clarify and separate the issues of persistent federated identity and credentials/authorization for AWS services from issues of Identity, authentication and attributes/claims for that Identity.

  
  
  • MHH中的身份只有1级 AWSIdentityManager 。
  
  
  • MHH中的SignIn有一个协议， AWSSignInProvider ，以及该协议的两个实现（加上我制作的一个）：
    
    
  • Identity in MHH has only 1 class AWSIdentityManager.
  • SignIn in MHH has one protocol, AWSSignInProvider, and two implementations of that protocol (plus one I made):
  
  
  1. AWSGoogleSignInProvider ：
     的OpenID-Connect / OAuth实施适用于Google +的AWSSignInProvider
  
  
  2. AWSFacebookSignInProvider ：Facebook的AWSSignInProvider的OAuth /专有实现
  
  
  3. AWSCUPIdPSignInProvider ：
     的OpenID-Connect / OAuth实现AWSSignInProvider for Amazon AWS Cognito您的用户池服务（这在fork上可用） ed repository）
  
  
  1. AWSGoogleSignInProvider: OpenID-Connect/OAuth implementation of AWSSignInProvider for Google+
  2. AWSFacebookSignInProvider: An OAuth/Proprietary implementation of AWSSignInProvider for Facebook
  3. AWSCUPIdPSignInProvider: OpenID-Connect/OAuth implementation of AWSSignInProvider for Amazon AWS Cognito Your User Pools service (this is available on a forked repository)




mobile-hub-helper仅记录在。 h文件。这些可以通过appledocs处理成文档，如果您对类结构有一个概述（不存在，但我会尝试提供），那么那里的注释非常好。

The mobile-hub-helper is documented only in the .h files. These can be processed into documentation by appledocs, and the comments there are pretty good if you had an overview of the class structure (which does not exist but I will attempt to provide).

SDK身份验证流程

AWS记录的身份验证流程过于简单化，无助于了解如何使用身份验证完成身份验证SDK和Mobile Hub Helper。下图试图说明使用AWS服务（如S3和DynamoDB）的身份验证（登录）和授权（凭证）如何工作。

The authentication flow documented by AWS, is an oversimplification and does not aid in understanding how the authentication is accomplished using the SDK and Mobile Hub Helper. The following diagrams attempt to convey how identity authentication(login) and authorization(credentials) to use AWS Services (like S3, and DynamoDB) works.




了解Cognito



• 了解Cognito最初会因各种原因而混淆：
  原因：身份验证，授权和身份
  
  分布式系统中的管理很复杂。有许多派对具有不同的
  角色，并与密钥，令牌和
  
  签名进行精心规定的交互。最终用户，依赖方（RP）身份
  
  提供商（IdP）正在使用的资源（RS）和资源所有者
  
  （RO）。 OpenId Connect和OAuth2.0
  
  标准文档使用此术语。由于明白的原因，AWS并未始终使用此
  术语。但是当使用Cognito时，它们的概念和实体都在那里。
  
  
  
  
  • 网上有一些很好的OpenID连接概述（例如： http://nordicapis.com/api-security-oauth-openid-connect-depth/ ）和
    a审查这些将有所帮助。
  
  

  Cognito Naming

  
  

  • Cognito是AWS创建的单一名称，涵盖许多功能
    和角色。

  • Cognito is a single name created by AWS to cover many functionalities and roles.

  
  
  1. Cognito有RESTFUL Web API，但也有
     Cognito SDK。 SDK调用和API消息未命名为
     
     相同，SDK调用进行多个条件API调用。
  
  
  2. Cognito可以联合身份提供者。它可以持久存在并且与来自不同身份的经过身份验证的用户建立联系
     
     提供商（因此它可以记住您的Google +和您的Facebook
     
     身份并将其与单个相关联Cognito identityId。）
  
  
  3. Cognito可以为用户以及
     身份验证用户提供持久性identityId（如果匿名，
     跟随使用钥匙串数据的IOS设备）。这些存储在所谓的
     标识池中（不要与用户池混淆）。对于
     经过身份验证的用户，您的应用
     为不同设备上的用户接收相同的identityId。未经身份验证的（访客）identityId遵循
     单个设备。
  
  
  4. Cognito可以存储（称为同步）状态数据IdentityId（在AWS服务器上
     ），适用于经过身份验证和未经身份验证的
     用户。
  
  
  5. Cognito有一个AWSCredentialsProvider（使用AWS服务的AWS Credentials
     的来源（Cognito以及S3，DynamoDB等）
  
  
  6. Cognito可以创建一个名为User Pool的OpenID Connect服务器，
     ，Cognito Identity可以使用它来验证用户。
  
  
  7. Cognito是新的，但AWS联合身份和AWS身份
     管理和AWS凭证不是，所以有很多类
     ，责任重叠。命名约定是
     令人困惑（考虑名称
     AWSCognitoIdentityCognitoIdentityProvider！）。对用户池使用cognito
     品牌名称，实际上是一场噩梦。
     AWSCognitoIdentity是Cognito Federated Identity C FI但是
     AWSCognitoIdentityProvider就像用户池一样，
     身份验证提供程序也称为身份提供者。
  
  
  1. There is the RESTFUL web API to Cognito, but there is also the
     Cognito SDK. The SDK calls and the API messages are not named the
     same, and SDK calls make multiple and conditional API calls.
  2. Cognito can federate identity providers. It can persist and
     association betwene authenticated users from different identity
     providers (So it can remember your google+ and your facebook
     identities and associated them with a single Cognito identityId.)
  3. Cognito can provide persistent identityId (which, if anonymous, follow an IOS device using keychain data) for users as well as authenticated users. These are stored in what is called an Identity Pool (NOT to be confused with a User Pool). Your app receives the same identityId for a user on different devices for authenticated users. Unauthenticated (Guest) identityId’s follow a single device.
  4. Cognito can store (known as "Sync") state data IdentityId’s (on the AWS server), which works for authenticated and unauthenticated users.
  5. Cognito has a AWSCredentialsProvider (a source for AWS Credentials for using AWS Services (Cognito but also S3, DynamoDB, etc)
  6. Cognito can create an OpenID Connect server called a User Pool, which can be used by Cognito Identity to Authenticate users.
  7. Cognito is new, but AWS Federated Identities and AWS Identity Management and AWS Credentials are not, so there are lots of classes with overlapping responsibility. And the naming conventions are confusing (consider the name AWSCognitoIdentityCognitoIdentityProvider! ). The use of the "cognito" brand name for userpools, really is a nightmare. An AWSCognitoIdentity thing is Cognito Federated Identity CFI but an AWSCognitoIdentityProvider thing is a thing like userpools an authentication provider also called an identity provider.




• SDK类名称令人困惑。但除少数例外情况外，以 AWSCognitoIdentity （但不是AWSCognitoIdentityProvider）开头的类与credentialsProvider / IdentityProvider有关，以 AWSCognitoIdentityProvider 开头的类与Oauth / Open Id Connect提供商和其他分布式提供商有关。身份提供者（facebook）。

• SDK class names are confusing. But with few exceptions, classes starting with AWSCognitoIdentity (but NOT AWSCognitoIdentityProvider) are about the credentialsProvider/IdentityProvider, classes starting with AWSCognitoIdentityProvider relate to Oauth/Open Id Connect providers and other distributed identity providers (facebook).

  词汇表/同义词

  这些术语在整个AWS文档和营销材料中使用得很松散。这是尝试通过对AWS可互换使用的术语进行分组来理清术语。

  These terms are used loosely throughout the AWS documentation and marketing material. This is an attempt to sort out the terminology by grouping terms that are used interchangeably by AWS.

  
  
  • 身份提供者，身份验证提供者，登录提供者，联合
    身份提供商
  
  
  • Amazon Cognito，Cognito凭证提供程序，cognito身份（所有
    似乎都指代相同的类/流程）
  
  
  • Cognito用户池，Cognito您的用户池，用户池。 CUP 身份提供商，即身份验证提供商
  
  
  • Cognito身份池，池，Cognito池，身份池。偶尔称为身份提供者（似乎不正确）但它从未被称为身份验证提供者
  
  
  • 开发人员身份，开发人员身份验证身份，开发人员
    提供者，开发人员身份提供者，所有习惯请参阅私有外部身份提供商。
  
  
  • 身份是Cognito文档中经常被滥用的术语。重要的是要了解Cognito管理的两种不同的身份。 identityId （应为小写）是Cognito与凭据关联的持久唯一名称，用于联合不同的 Identity 提供程序，Identity（大写）是一个来自身份提供商的经过身份验证的标识符。
  
  
  • identityId 身份ID，ID（如get-id），身份，identityId
  
  
  • 身份
  
  
  • 联合意味着多件事。
  
  
  • Web身份联合 - 在AWS上联合身份的早期方式
  
  
  • Cognito联合身份
  
  
  • BYOI（通常通过OpenId-Connect，用户可以使用google，facebook或其他身份提供商（可能是开发人员提供的身份）。
  
  
  • Identity provider, authentication provider, Login provider, federated identity provider(s)
  • Amazon Cognito, Cognito credentials provider, cognito identity (all seem to refer to the same class/process)
  • Cognito user pool, Cognito Your User Pools, user pool. CUP is an identity provider aka authentication provider
  • Cognito identity pool, pool, cognito pool, identity pool. Occasionally called an identity provider (which seems incorrect) but it is never called an authentication provider
  • Developer identity, developer authenticated identities, developer provider, developer identity provider, all used to refer to private external Identity Providers.
  • Identity is a term often misused in Cognito documentation. It is important to understand there are two different kinds of identity that Cognito manages. identityId (which should be in lower case) is the persistent unique name that Cognito associates with credentials and uses to federate different Identity providers, and Identity (upper case) which is an authenticated identifier from an Identity Provider.
  • identityId Identity ID, id (as in get-id), identity, identityId
  • Identity
  • Federation means multiple things.
  • Web identity federation - an earlier way of federating identity at AWS
  • Cognito federated identities
  • BYOI (bring your own idenity) where a user may use google, facebook or another identity provider (perhaps a developer provided identity) usually through OpenId-Connect.

  IdentityId行为

  
  
  • 身份ID如下所示：
    us-east-1：982396fs-841e-3cdd-9r43-e7ac41bhbcb28
  
  
  • 在IOS设备上维护identityId在钥匙串条目中。
    对于未经身份验证的IdentityId，它会保持不变，直到您清除
    的钥匙串（这可以通过Simulator在模拟器中完成 - >重置
    内容和设置...）。那时IdentityId被放弃了。
    它没有被禁用，它再也没有被使用过。
  
  

  • 当用户进行身份验证时，身份验证会禁用未经身份验证的identityId（
    identityId将永久使用在
    identityPool条目的Logins数组中标记为DISABLED。您可以在Cognito控制台中看到这一点。）当前在设备上的
    。有一个例外：如果这是第一次对此身份进行
    身份验证，则未放弃未经身份验证的identityId，但
    与身份相关联，并用作经过身份验证的
    身份ID转发。

  • An identity id looks something like this: us-east-1:982396fs-841e-3cdd-9r43-e7ac41bhbcb28
  • The identityId is maintained on an IOS device in a keychain entry. For an unauthenticated IdentityId it remains the same until you clear the keychain (This can be done in simulator by Simulator -> Reset Content and Settings…). At that point that IdentityId is abandoned. It is not disabled, it is just never used again.

  • When the user authenticates, authenticating disables the unauthenticated identityId (the identityId will be permanently marked with DISABLED in the Logins array in the identityPool entry. You can see this in the Cognito console.) that is currently on the device. There is one exception: If this is the first time the authentication takes place for this Identity then the unauthenticated identityId is not abandoned but is associated with the Identity and used as the authenticated identityID going forward.

  从
  合并多个身份（意味着用户名不是IdentityId）不同的身份提供者放弃（禁用）其中一个identityId和
  将Identities与另一个identityId相关联。已禁用
  只要发生这种情况，就会创建Id。这些被遗弃的identityId在
  的signin数组中标记为DISABLED，即cognito identityPool。

  Merging multiple Identities (meaning usernames not IdentityId’s) from different Identity providers abandons (disables) one of the identityId's, and associates both Identities with the other identityId. Disabled Id’s get created whenever this happens. These abandoned identityId's are marked with DISABLED in the Logins array in the cognito identityPool.

  在实践中，此过程创建了对唯一identityIds的合理使用
  禁用的只有当用户在新的
  设备上进行身份验证时才会创建（在测试中可能很麻烦，因为它会导致
  禁用和未使用的identityId，因为测试人员注销并且在$中b $ b多次使用多个id）。但在实践中，常见用例不会创建这种禁用的identityIds。用户将：

  In practice this process creates a reasonable use of unique identityIds with disabled ones only getting created when a user authenticates on a new device (It can be bothersome in testing as it creates a barrage of disabled and unused identityId’s as the tester logs out and in multiple times with multiple id’s). But in practice the common use case would not create this barrage of disabled identityIds. A user would:

  Connect - 获取未经身份验证的ID - 身份验证 - 并使用相同的
  ID。没有创建遗弃的ID。

  Connect – get an unauthenticated id - authenticate – and use the same ID. No abandoned id is created.

  AWSIdentityProviderManager

  
  

  • AWSIdentityProviderManager是管理联合AWSIdentityProviders的协议

  • AWSIdentityProviderManager is the protocol that manages federated AWSIdentityProviders

  在mobile-hub-helper中AWSIdentityManager是AWSIdentityProviderManager

  In mobile-hub-helper AWSIdentityManager is the AWSIdentityProviderManager

  
  

  • 所有需要做的就是返回凭证提供者登录
    字典，包含提供者名称和ID令牌。 AWSIdentityManager
    仅返回单个标识
    提供程序的提供程序名称和标记。它只是从
    AWSSignInProvider获取名称和令牌并返回。 （有一个分叉，修改了
    ，增加了返回登录词典中所有当前登录的
    提供程序。）

  • All it needs to do is return to credentials provider a logins dictionary, with providers name and ID Token. AWSIdentityManager only returns the providername and token for a single identity provider. It simply gets the name and token from the AWSSignInProvider and returns. (There is a fork with a modification that adds the ability to return all of the current logged in providers in the logins dictionary.)

  修改后的AWSIdentityManager维护一个名为cachedLogins的NSDictionary
  。每个新登录都会向缓存添加一个登录名（身份
  提供程序名称和id标记）。然后登录始终返回
  整个loginCache。这是支持身份合并的原因。

  As modified AWSIdentityManager maintains an NSDictionary called cachedLogins. Each new login adds an login (an identity provider name and id token) to the cache. Then logins always returns the whole loginCache. This is what supports identity merging.

  当凭据提供程序调用它关联的
  AWSIdentityProviderManager登录时方法，并找到一个
  登录列表，而不只是一个它将在其数据库中合并那些登录
  的identityId并禁用其中一个的identityId。
  如何知道哪个ID与哪个登录有关？ ID令牌包含
  编码的可解密（将令牌粘贴到 https://jwt.io 中以查看
  你自己）一套索赔，其中一个是身份（例如：用户名）

  When the credentials provider calls it’s associated AWSIdentityProviderManager logins method, and finds a list of logins instead of just one it will merge the identityId's for those logins in it’s database and disable the identityId of one of them. How does it know which ID goes with which login? The ID Token contains an encoded decryptable (paste the token into https://jwt.io to see for yourself) set of claims, one of which is the identity (ex: username)

  注意：即使你有一个有多个相关的identityId登录，在Mobile Hub Helper中，您只能通过一个AWSSignInProvider进行身份验证。凭据与合并的identityId相关联，但在mobile-hub-helper中，即使您使用多个身份提供程序登录，也始终通过活动的AWSSignInProvider（身份验证提供程序）访问该identityId。您的应用程序可以跟踪所有AWSSignInProviders并独立于AWSIdentityManager访问它们，但从AWSIdentityManagers的角度来看，您使用其中一个登录。在实践中，这几乎没有什么影响（例如，你试图从不同的提供者那里获得像imageURL这样的声明）。

  Note: Even though you have an identityId that has multiple related logins, in Mobile Hub Helper you are only ever authenticated by one AWSSignInProvider. Credentials get associated with the merged identityId, but in mobile-hub-helper access to that identityId is always via the active AWSSignInProvider (authentication provider) even if you are logged with multiple identity providers. Your app can keep track of all of the AWSSignInProviders and access them independently of AWSIdentityManager, but from AWSIdentityManagers point of view you are logged in with one of them. In practice this has little impact (until you try to get "claims" like imageURL from different providers for instance).

  关于合并身份

  
  

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

  • Currently the AWSIdentityManager does not support identity merging. I have a forked repository https://github.com/BruceBuckland/aws-mobilehub-helper-ios from the github repository that adds that capability, and adds a Cognito User Pools Identity Provider AWSSignInProvider (AWSCUPIdPSignInProvider.swift).

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

  You can probably think of all sorts of gotcha’s when merging identities.

  如果我尝试合并来自同一个提供商的两个身份怎么办？
  （字典键不一样吗？）

  What if I try to merge two identities from the same provider (wouldn’t the dictionary keys be the same?)

  什么如果我尝试合并两个身份，每个身份都与来自与之关联的同一提供者具有不同的
  身份（同样，他们
  会创建两个具有相同密钥的实体）。

  What if I try to merge two identities, each of which has a different identity from the same provider associated with it (and again they would create two entities with the same keys).

  Cognito很好地管理这个并且拒绝尝试合并无法合并的
  身份。拒绝发生在登录时间
  （当您尝试获取凭据时，凭据提供程序将
  拒绝包含不可合并的
  identityId的登录词典）

  Cognito manages this beautifully and rejects attempts to merge
  identites that cannot be merged. The rejection happens at login time (when you would try get credentials, the credentials provider will reject the logins dictionary that contains an un-mergeable identityId)

  Cognito埋葬数据的地方

  
  

  • Cognito将密钥链存储在包含最后使用的identityId的设备上。在调用credentialsProvider.credentials（IOS SDK名称）时，credentialsProvider / identityProvider对象使用它来重新使用现有标识（例如未经身份验证）并避免创建未使用的标识，除非用户确实不打算登录或恢复。

  • Cognito stores a keychain on the device that contains the last identityId that was used. This is used by the credentialsProvider/identityProvider object upon a call to credentialsProvider.credentials (IOS SDK name) to re-use an existing identity (for example unauthenticated) and avoid creating unused identities unless the user truly is not going to log in or resume.

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

  Mobile-Hub-Helper’s AWSSignInProvider’s and AWSIdentityManager store an indication of an open session state in NSUserDefaults. These are used to re-start the session if the app is terminated and restarted.

  AWSSignInProvider的商店NSUserDefaults，有时也在IOS Keychain，为他们自己内部目的（如保留对用户名或imageURL或令牌的轻松持久访问）

  AWSSignInProvider’s store NSUserDefaults too, and sometimes in the IOS Keychain, for their own internal purposes (like retaining easy persistent access to a username or imageURL or token)