Amplify-js: Difference between cognitoIdentityId and cognito's sub

Created on 5 Sep 2018  ·  11Comments  ·  Source: aws-amplify/amplify-js

Which Category is your question related to?
Auth
What AWS Services are you utilizing?
Cognito + Amplify
Provide additional details e.g. code snippets

I have an authenticated user that when hitting an authenticated API, the APIGatewayEvent request identity object in the lambda function looks like the following:

APIGatewayEventRequestContext.identity: {
    accessKey: string;
    accountId: string;
    apiKey: string;
    caller: string;
    cognitoAuthenticationProvider: string;
    cognitoAuthenticationType: string;
    cognitoIdentityId: string;
    cognitoIdentityPoolId: string;
    sourceIp: string;
    user: string;
    userAgent: string;
    userArn: string;
}

In most tutorials I've seen people use the cognitoIdentityId as a primary key in their Dynamo DB table. This cognitoIdentityId looks along the lines of us-east-1:9383883-7c06-4e84-8637-01b966cd2323.

This looks very different than sub that's found on cognito, which looks more like d014f2323-f1e8-4694-9d97-c223232. I'm leaning towards using sub as the primary key, however, it makes me feel a little uneasy that given the above event request identity object, the only way to retreive sub is by parsing the cognitoAuthenticationProvider key:

i.e. event.requestContext.identity.cognitoAuthenticationProvider.split(“:”)[2] // => returns sub

I guess my questions are:

1) Why is sub so hard to get in this object? Is it safe to do so?
2) What's the purpose of cognitoIdentityId? Is it meant to be used as a public id?
3) Is it okay to use cognito's sub as a primary key for a dynamo db table?

Thank you in advance

Cognito

Most helpful comment

Hello, there must be more implications to using one over the other. Which value, sub or identity id, should be used as a unique identifier for a user in say a dynamo table.

For instance, if a Facebook or google login api was offered in a client app along with custom login in option how would these impact sub and identity id values.

All 11 comments

@yuntuowang @haverchuck just want give this ticket item a bump and see if there are any clarifications i should make. thanks

1) Yes, you should be able to access sub through cognitoAuthenticationProvider. See this stackoverflow post explaining just that: https://stackoverflow.com/questions/42359990/is-there-any-way-to-get-the-cognito-username-in-aws-lambda
2) IdentityId is the Id of your user in the Identity pool from Cognito Federated Identities.
3) I don't see why you can't do that.

  1. You may be able to do some claim mapping. Similar example can be found here.

  2. cognito identity id simply stands for the unique id for each identity. It can be used as public id.

  3. Yes, since sub value is unique, so it can be use as primary key for sure.

I am closing this issue for now, but please feel free to reopen it if your questions have not been addressed.

Hello, there must be more implications to using one over the other. Which value, sub or identity id, should be used as a unique identifier for a user in say a dynamo table.

For instance, if a Facebook or google login api was offered in a client app along with custom login in option how would these impact sub and identity id values.

Are there updates on this? @shan4993 's question is crucial to some applications!

Not sure why this was closed, I think @shan4993 made a good point. Is there any one on the @aws team to comment on that?

Quick question: Wouldn't cognitoIdentityId be the safer choice to index users in, say, DynamoDB tables because the user could be from a non-Cognito Auth Provider (such as Google/Facebook)? For these non-Cognito users, sub doesn't exist, right?

Does anyone know the answer to @jeyashankher's question? Does sub exist for non-cognito federated users? such as facebook/google?

per the above stackoverflow posts _ a commenter points out :

"sub is for subject as per JWT specification"
https://en.wikipedia.org/wiki/JSON_Web_Token

would that mean that if you used something other than cognito for your authentication that sub does not exist ?
in that case it seems it would make sense to use id _

the top answer on the post seems to suggest sub comes first when using cognito for auth and that in certain cases a refresh would be required then to obtain the id _ those details might be important to some users of cognito

at this point until we see either an authoritative response or someone who has tested all these possible configurations i am going to move forward using id as my cognito unique user identifier and maybe keep a record of sub next to it _

i assume that if i use cognito exclusively for auth then sub & id will be the same and both will exist

fyi: i have been wondering about this since i first touched cognito 2 years ago and this is the closest i have gotten to understanding what the difference is between sub and id _ thank you to all the answers coming from the community and individual experiences

i think it is worth noting that with certain configurations id & sub & username are all 3 the same value

i assume peeps with a deep understanding of all aws services can put these pieces together _ i assume internal aws teams are building products out of multiple internal products and i assume do not feel responsible to hold our hand clearing up details that are publicly available across N number of documents across M number of products _ really drives me nuts _ i am curious if anyone with an aws support account has found that they are able to get answers to these questions in a more satisfactory way

🌈 😺

This AWS example show what looks like sub as cognito-identity.amazonaws.com:sub

https://docs.amazonaws.cn/en_us/IAM/latest/UserGuide/reference_policies_examples_dynamodb_rows.html

Was this page helpful?
0 / 5 - 0 ratings