Are there any plans in improving the behavior with...
# ory-selfhosting
g
Are there any plans in improving the behavior with linking an oidc account? I think I saw a Github issue referencing this somewhere, but it already dates back a few years. We are currently lacking the ability to apply jsonnets and add missing identity traits / metadata when connecting an existing identity to a (new) oidc provider. The same jsonnets are applied when registering, but remain unused when connecting. If this "best-effort" application of jsonnets does not work, it would also be solved by providing the claim information in the settings webhook so it can be handled on our end. Are there any alternative work-arounds or plans to have any of those two solutions work?
m
Hello @gifted-waitress-14272 You have the use case where you have multiple OIDC providers available to sign up. Now users sign up with provider A. Later on they connect provider B to their account. Now the behaviour you are looking for is to update the traits with the data they get from provider B when they connect it - did I get that right? I think adding those traits through a separate settings flow sounds reasonable. One solution from the top of my head: You can check if the traits exists on login and if they dont you redirect to a "custom" settings page for the user to manually add them (or the normal one, but a custom might make it clearer to the user what is happening) Or are you looking to update the traits on every OIDC login? That is indeed still an open issue.
g
Having to do it manually kind of defeats the purpose and will very likely even create invalid data entries. We would for example want to see the e-mail address that corresponds to the user according to the oidc provider, but other use cases also include other types of info where it would not matter as much. I feel that if we would be able to access the claim data via the webhook body, we could easily do whatever we want with it without impacting any other Ory specific processes. That seems like the easiest route and it would also cover the log in scenario. For our use case specifically doing an update on every log in is not really required, although I feel like there definitely exist cases where you want to keep external information as up-to-date as possible without the need of manual intervention.
m
We would for example want to see the e-mail address that corresponds to the user according to the oidc provider, but other use cases also include other types of info where it would not matter as much.
So you are looking for a behaviour where the email address updates on the user identity every time they log in with their OIDC provider? I am not sure how it is in your use case, but personally as a user I would be pretty annoyed if e.g. my GitHub email address changes because I made changes to my email in Google.
if we would be able to access the claim data via the webhook body
agreed that seems like a good solution to me. I cant find the GitHub issue now, but maybe you can add it there?
g
That would indeed be annoying, but is not exactly our intended behavior 🙂. It would be more of a metadata type thing where we can do things like validation (not allowing the same email address that we already have listed on a different identity for example) or show the e-mail address that is used with each oidc provider. I will try to add to the GH issue when I come across it again 😄.
1
👍 1
@magnificent-energy-493 I think extending this PR to also include settings flow OIDC link updates would solve a lot. I feel like it would make a lot of sense to also include it in the settings flow if it also gets added to login for validation purposes. https://github.com/ory/kratos/pull/3922
m
Oh yea that is on the roadmap AFAIK, might be that its solved in the PR you linked or in a future one 🤔 But that is very good feedback, thanks for looking into it in such detail!
👍 1