Core - Should Userinfo include the issuer?
Maybe userinfo response should include the issuer as well?
Comments (13)
-
-
reporter 5.3.2. Successful UserInfo Response says:
NOTE: Due to the possibility of token substitution attacks (see Section 16.11), the UserInfo Response is not guaranteed to be about the End-User identified by the sub (subject) element of the ID Token. The sub Claim in the UserInfo Response MUST be verified to exactly match the sub Claim in the ID Token; if they do not match, the UserInfo Response values MUST NOT be used.
Need to make it more explicit? Like "can be used for attributes" ...
-
- changed milestone to Ammendment
-
reporter - edited description
- changed component to Core
-
reporter - changed status to open
Perhaps writing security consideration text for "not using Userinfo response for authentication"
-
reporter -
assigned issue to
-
assigned issue to
-
reporter - changed milestone to Errata
-
@Nat Sakimura - if you could supply the Security Considerations text you have in mind, that would be much appreciated.
-
As discussed on the 31-Jul-23 call, Nat plans to propose text.
-
Will be fixed by https://bitbucket.org/openid/connect/pull-requests/599
-
reporter Thanks for the PR. There were two points I was trying to make:
- The
sub
alone cannot be used as a user identifier. This seems obvious for us, but it may be worth mentioning. - In the case of signed responses, would there be a requirement around the values of the
iss
of the JWS and what thesub
was paired with?
They are not currently captured.
Also, since I have seen a case where ID Token was returned from the token endpoint in exchange for a refresh token recently, the following question came to my mind. It could be a different issue but:
- Is it worth mentioning that ID Token returned in response to the authentication request can be used for user authentication?
WDYT?
- The
-
We discussed this on the 7-Aug-23 call. Point 1 is already addressed. We’ll address point 2 by adding a statement that the “iss” for signed UserInfo responses must be the OP’s issuer.
-
- changed status to resolved
- Log in to comment
We return "sub" to give the client an internal integrity check. Returning "iss" wouldn't increase security because the OP can always lie. You already shouldn't rely upon the UserInfo response for authenticating the user. There doesn't appear to be a strong argument for returning it.