Here is a snippet of my post-login action:
// HP: After an action for 'oidc-basic-profile' is triggered for a user,
// no second action for 'oidc-basic-profile' is triggered for the same user
// before the the 'oauth2-refresh-token' action for the first authorization is triggered.
// If this is not true, the 'connection_uuid' initially associated with the first authorization might then be associated to the second one.
let connection_uuid;
if (event.transaction.protocol === "oidc-basic-profile") {
let connections = event.user.app_metadata.connections || [];
console.log("Pre-login connections:", connections);
connection_uuid = uuidv4();
connections.push(connection_uuid);
api.user.setAppMetadata("connections", connections);
console.log("Post-login connections:", connections);
}
else if (event.transaction.protocol === "oauth2-refresh-token") {
const refresh_token_id = event.refresh_token.id;
if (event.user.app_metadata[refresh_token_id]) {
connection_uuid = event.user.app_metadata[refresh_token_id];
}
else {
let connections = event.user.app_metadata.connections;
console.log("Pre-refresh connections:", connections);
connection_uuid = connections.pop();
api.user.setAppMetadata("connections", connections);
console.log("Post-refresh connections:", connections);
api.user.setAppMetadata(refresh_token_id, connection_uuid);
}
}
if (connection_uuid) {
api.accessToken.setCustomClaim("fabric_connection_uuid", connection_uuid);
console.log("Set fabric_connection_uuid:", connection_uuid);
}
Basically, on oidc-basic-profile
i create a random connection_uuid
(what in this thread we have been calling couplingID
) and store it in the app metadata. On the first oauth2-refresh-token
i get the connection_uuid
and store it against the refresh_token_id
. From then on, all access tokens generated with that refresh token will have the same connection_uuid
as a custom claim.
This works well as long as the user does not create a second authorization before oauth2-refresh-token
of the first one is run. If that’s the case, a connection_uuid
initially assigned to an access token of the first authorization (during oidc-basic-profile
) might then get assigned to an access token of the second authorization.
Using event.session.id
to distinguish the two authorizations during oidc-basic-profile
might not work as they could have the same session id.
Isn’t this use case common?