Open cflee opened 3 months ago
I have a proposed patch but I am not submitting it as a PR yet, as I am still working on getting it tested with a Corppass relying party, and trying to collect more data to confirm whether the uuid
field needs to be made unique per user-and-UEN combination. I'm not sure if/when that will be done, so I'm leaving this here first in case someone else could use it.
From 7b9a29c93c63e8d5f53b45ea1c7d82117e7e2128 Mon Sep 17 00:00:00 2001
From: Lee Chiang Fong <lee_chiang_fong@tech.gov.sg>
Date: Thu, 23 May 2024 18:57:28 +0800
Subject: [PATCH] fix: corppass id token sub
---
lib/assertions.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/assertions.js b/lib/assertions.js
index 1ba6d17..cf48fd6 100644
--- a/lib/assertions.js
+++ b/lib/assertions.js
@@ -171,7 +171,7 @@ const oidc = {
aud,
}
- const sub = `s=${nric},u=${uuid},c=SG`
+ const sub = `s=${nric},uuid=${uuid},u=${uen}${nric},c=SG`
const accessTokenClaims = {
...baseClaims,
--
2.39.3 (Apple Git-146)
From some folks' testing against Corppass staging, they report that they receive a different u value for the same UIN logging into a different UEN to the same Corppass relying party.
Apparently sometimes the same UIN and same UEN to the same system results in a different u=...
value from Corppass production, so something is wrong with our understanding – will hold off on submitting this change.
Describe the bug
sub
claim on Corppass ID token is missinguuid
field, and theu
field should be different when a given user logs in to different UENsTo Reproduce Steps to reproduce the behavior:
s=F1234567P, u=0f14a2fc-09c2-4780-95f0-8c28347f2780, c=SG
Expected behavior ID token's
sub
claim should match what is described in the Corppass spec:Also, from a previous comment https://github.com/opengovsg/mockpass/issues/615#issuecomment-1794139122 (on a different issue):
The
uuid
field should be present in case there are systems that expect or consume it. It is unclear whether this UUID is expected to be the same for a given user across different UENs, but it seems like a reasonable guess for now.The
u
field is present, but it is not unique per user-and-UEN combination. From some folks' testing against Corppass staging, they report that they receive a differentu
value for the same UIN logging into a different UEN to the same Corppass relying party. The different behaviour in Mockpass causes problems for systems that rely on receiving a uniqueu
field value per user-and-UEN combination.