OIDC OP 3.4 and issueIdTokenViaRefreshToken

[Wessel, Keith]

Correct, the spec states that the claims in the ID token must be the same as when the user originally authenticated. Short-term, that makes sense, but as you stated, that can be a challenge months in the future. It does seem like it could create problems.

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Wednesday, August 2, 2023 11:26 AM
To: Wessel, Keith <kwessel at illinois.edu>; Shib Users <users at shibboleth.net>
Subject: Re: OIDC OP 3.4 and issueIdTokenViaRefreshToken

> An excellent point. I'll pass that along to our app developers. A better
> question is why the IdP ignored the spec and included it in V3.3 and earlier
> of the plugin. But since we know what the spec states, that's relatively moot
> at this point.

Well, it didn't ignore anything in the sense that it violated any rules, but why it defaulted that, I don't know. I presume it's some kind of historical thing but I didn't see any sign that there was any spec text talking about it being advisable or suggested, just that it "might not be there". Which admittedly is a soft "it probably will" but I have no idea why.

The access token and the refresh token that refreshes it should be exclusively about the UserInfo endpoint, and there's no ID token there ever. It's just needless contamination of function, not to mention you'd have to save off all the data enough to reproduce that token a year later when you shouldn't have to.

And it's much worse if you end up changing the ID token claims in that copy. What the heck would that even mean? And is any app gonna notice? I bet not.

Seems like a good recipe for mistakes to me.

-- Scott