Hi Garret, Simon, community,
We were recently trying to achieve something similar but, after trying a
similar approach to the one you discuss here we decided not to use that
because even though this seemed to work at a first glance, we soon realise
that things would quick get out-of-sync if the users removed and/or added
links after the creation of their accounts. It seemed odd at the beginning
but after giving it some thought it made sense: we were adding an attribute
to the user (not to the link) so, removing the link won't remove this
property (we then wrote an EventListener to circumvent this) but the whole
set up seemed very convoluted so we decided to try a different approach:
Why not extract the "Provider User ID" from the link itself instead of a
User Attribute? Well this approach seemed to work quite well. No more
problems maintaining mappings from Provider to User Attribute and then from
User Attribute to token and no more out-of-date information that we needed
to address.
Is this approach correct? Am I missing an obvious reason not to use this
approach (can you see a reason why this may be unsafe or fall in some
problems in the future)?
I've written a SPI that does exactly this:
https://github.com/leandronunes85/idp-user-id-token-mapper and I would
really appreciate if someone could take a look and peer-review it :)
Thanks,
Leandro Nunes