Support OIDC in API-based settings flow

[MortalKastor]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [X] This issue affects my Ory Network project.
• [ ] I have joined the Ory Community Slack.
• [ ] I am signed up to the Ory Security Patch Newsletter.

Describe your problem

While it's now possible to sign in with OIDC in apps, thanks to #3216, there's currently no way to:

• know which OIDC are available
• know which ones are linked
• link an OIDC
• unlink an OIDC

Describe your ideal solution

OIDC listing, status and linking/unlinking should be part of the settings flow for Native Apps

Workarounds or alternatives

Use #2346 which offer the forementioned features, but, as the PR as been closed and superseded by #3216, this is not a future-proof solution. Additionally, the OIDC sign in flow was quite different in the closed PR to what is now in master, so it doesn't sound sensible to choose to go with an incompatible (and unmaintained) fork.

Version

master (as no release ships #3216 yet)

Additional Context

We added OIDC support in our app using #2346, and we're now switching to mainline Kratos after noticing OIDC support is now baked-in (and the PR we were following got closed). That's when we found out the scope of that PR and the one that superseded it (#3216) didn't exactly match (OIDC sign in + OIDC settings vs OIDC sign in only).

[WoodyWoodsta]

I'm sortof confused why support for this wasn't added at the same time as https://github.com/ory/kratos/pull/3476. It seems to me like it should be similar changes to just another flow strategy.

Go is not my fluent expertise, so it would be really helpful to know if there was a more fundamental reason why this was not done at the same time?

If there is no reason, I can try and patch the settings flow to include this native token support.

[jonas-jonas]

This was an oversight, when we planned and implemented this in #3476. I am not aware of a more fundamental reason for not implementing this. Contributions are definitely welcome here.

[WoodyWoodsta]

No problem, and thanks for the reply. I'll give it my best shot, but as I said, I don't usually write go, and it looks like the style of the settings strategy is subtly different from registration and login.