Repository navigation
Conversation
There was a problem hiding this comment.
I'm strongly against adding this. Token exchange should not permit adding linking to existing users. That would be the equivalent of an application updating a users credentials through account linking.
|
@stianst We are between a rock an a hard place. Without this feature, our 10k or so existing users would not be able to log in to the new game without first visiting our website on a different device and performing the account linking. How could we implement this in a way that is acceptable to you? |
|
I'd open a discussion on the dev mailing list around this if you do want to contribute something. Although, from my perspective any best practices around OAuth/OIDC recommends using an embedded user-agent. See https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12 for example. I have no clue about console/games development, but I would be very surprised if they don't support this flow. Other alternatives could be CIBA or OAuth Device Grant. Both may come to Keycloak at some point, hopefully soon. I can remember we discussed this somewhere, but not sure where. Perhaps also send a question on the user mailing list if anyone else has done something. |
|
Adding some justification why I'm against this:
|
|
Thanks for your thoughts and clarification, I think I'm starting to understand, but please bear with my if I'm barking up the wrong tree: The first objection is that a malicious application could perform the external token exchange using a token that does not belong to the user, thereby associating their KC account with an IdP account that is controlled by a malicious third party, thereby allowing hijacking of the user's KC account. The second objection is that, once an app has acquired a user's third-party token, it can perform the link without requesting the user's approval. Is that correct? |
|
#1 Not quite - the malicious application may have gained access to a users account in some social provider that the user doesn't care about all that much so they have used an unsafe password. The application can now link this social provider this user didn't care about to then gain full access of the user account. #2 Yes. A user should control if they want to enable social login to their Keycloak account, not an application |
|
Ok, now I think I understand. So if our deployment provides & trusts eg Sony as an IdP and user A has an old Sony account with a weak password that they never use, but has the same email address, then a compromise of said Sony account would allow the attacker to get a Sony token which they could use to link accounts and gain control of the user's KC account. |
|
Only thing I'm not sure about is how that's any different to the browser-based flow? Surely if a malicious party compromised a Sony account with a weak password, they could just enter said password into the browser and link accounts that way. What am I missing? |
|
Only if automatic account linking is enabled, which is something we don't recommend. Further, there's a difference between a login flow to link, and just linking with some access token, which is the case here. I'm going to close this for now - as I mentioned please open discussions on the mailing list around this. That way we can include a wider audience and perhaps there are others that have solutions for this already. Again, all specs recommend using standard redirect based flows - I would be very surprised if consoles are not able to integrate cleanly with OAuth/OIDC these days. |
Allows a federated identity link for an existing user to be created when using external token exchange, provided: