Include deviceKey in pretokengeneration refresh event

[mattiLeBlanc]

Is this related to a new or existing framework?

Angular

Is this related to a new or existing API?

Authentication

Is this related to another service?

congito

Describe the feature you'd like to request

The current v2 Refresh event for pretokengeneration trigger looks like:

{
    "version": "2",
    "triggerSource": "TokenGeneration_RefreshTokens",
    "region": "[REGION]",
    "userPoolId": "[USERPOOL_ID]",
    "userName": "[USERNAME]],
    "callerContext": {
        "awsSdkVersion": "aws-sdk-unknown-unknown",
        "clientId": "[CLIENT_ID]"
    },
    "request": {
        "userAttributes": {
            "sub": "[ID[",
            "cognito:user_status": "CONFIRMED",
            
        },
        "groupConfiguration": {
            "groupsToOverride": [
            
            ],
            "iamRolesToOverride": [],
            "preferredRole": null
        },
        "scopes": [
            "aws.cognito.signin.user.admin"
        ]
    },
    "response": {
        "claimsAndScopeOverrideDetails": null
    }
}

It would be very helpful if the deviceKey would be included in the refresh payload.
Currently , appsync will trigger amplify-auth to do a token refresh , so I can't add extra data via clientMetaData which I can include during the login.

Unless we can configure a custom payload that can be use during the auto tokenRefesh, it would be helpful to at least get the deviceKey in the event payload.

My my use case is that I have 1 cognito user being able to login for more than one Residents.
So one family member, gets access to Resident data with the same cognito user (email address). Before I would store the residentId in a cognito attribute but that is not scalable. So now I create a token in dynamodb and on login Inject the token:

this.signIn({ username, options: { clientMetadata: { tokenId } } }

Now the token will be available in the pretokengeneration trigger and I can query the token, extact the residentId and enrich my accessToken with this residentId so my graphql queries can fetch the residentId from the identities claim. Very secure.

However, on tokenrefresh, the tokenId I injected is lost and there is no residentId persisted with cognitoID, so all of a sudden the logged in session is broken.

(Option A ) IF I could inject the tokenId again during the accessToken refresh, that would solve my issue, but as far as I know that is not possible.

So, else (Option B ) if I could have access to the deviceKey, I could use that to find the correct tokenId that is unique for this device Session. However that value is currently not available in the event object.

So, my only option now is to store the residentId and facilityId in the localstorage of the browser and pass them on as arguments. That will work, but it also opens up to possible abuse because if you would know other residentIds or facilityIds you could overwrite someone else data.
The cognito user is not locked to a specific Facility or residentId.

Is this something that can be done?

So Option A would be best, very flexible.
But otherwise Option B would be workable.

Thank you for your time.

Describe the solution you'd like

(Option A ) IF I could inject the tokenId again during the accessToken refresh, that would solve my issue, but as far as I know that is not possible.

So, else (Option B ) if I could have access to the deviceKey, I could use that to find the correct tokenId that is unique for this device Session. However that value is currently not available in the event object.

So, my only option now is to store the residentId and facilityId in the localstorage of the browser and pass them on as arguments. That will work, but it also opens up to possible abuse because if you would know other residentIds or facilityIds you could overwrite someone else data.
The cognito user is not locked to a specific Facility or residentId.

Is this something that can be done?

So Option A would be best, very flexible.
But otherwise Option B would be workable.

Thank you for your time.

Describe alternatives you've considered

My only option now is to store the residentId and facilityId in the localstorage of the browser and pass them on as arguments. That will work, but it also opens up to possible abuse because if you would know other residentIds or facilityIds you could overwrite someone else data.
The cognito user is not locked to a specific Facility or residentId.

Additional context

No response

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

[bobbor]

Hey @mattiLeBlanc

I will have a look at your question today, and see if (ideally) Option A is viable.
If it is not too much of effort, we can consider implementing Option A - should it not be possible.

Cheers Philipp

[mattiLeBlanc]

@bobbor I guess some where we would have to registered a onTokenRefesh clientMetaData payload.
I assume the paload would be active as login as there is a valid login session. When reauthenticated, the payload would be renewed.

Thank you for considering this, it would all me to offer a very secure option to continue using the claims from the token and not having to send any client data in the sensitive data.

[bobbor]

hey matti

while researching an answer to your question I found this and was wondering if deviceMetadata is a better solution than clientMetadata.

	const { AuthenticationResult } = await getTokensFromRefreshToken(
		{ region },
		{
			ClientId: userPoolClientId,
			RefreshToken: tokens.refreshToken,
			DeviceKey: tokens.deviceMetadata?.deviceKey,
			ClientMetadata: clientMetadata,
		},
	);

https://github.com/aws-amplify/amplify-js/blob/main/packages/auth/src/providers/cognito/utils/refreshAuthTokens.ts#L41-L49

that might involve some changes in signIn too, for the tokens to be correctly setup.
I'll check that.

[mattiLeBlanc]

@bobbor

/**
 * Options specific to Cognito Sign In.
 */
export type SignInOptions = AuthServiceOptions & {
    authFlowType?: AuthFlowType;
    clientMetadata?: ClientMetadata;
    preferredChallenge?: AuthFactorType;
};

Are you suggesting that we add deviceMetadata to the SignInOptions and that everything in deviceMetadata will be included in the token refresh. Now only deviceMetadata.deviceKey seems to be added.