Add admin API or control to support enabling new OIDC Providers for existing users in Kratos

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.
[ ] I have joined the Ory Community Slack.
[ ] I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

In a self-hosted deployment of Ory Kratos used within a SaaS product, managing user authentication through OIDC (OpenID Connect) providers poses a significant challenge when introducing new providers after users have already registered or logged in using an existing one.

Scenario

Initial Setup

The system utilizes Ory Kratos for identity and authentication management.
Users have registered and authenticated using an OIDC provider, such as Google.
These users are employees of various corporate clients who access the SaaS product using their corporate email addresses.

Change in Authentication Method

At a later stage, support for an additional OIDC provider, such as Microsoft or Okta, is added to the system.
This change may occur due to corporate clients transitioning to a different primary Identity Provider (IdP) for their Single Sign-On (SSO) needs.

The Challenge

Lack of Administrative Control

No Administrative API: Ory Kratos does not provide an administrative API or mechanism to programmatically enable or register the new OIDC provider for all existing identities in the system.
Cannot Centrally Manage Providers: Administrators cannot centrally manage or automate the association of the new OIDC provider with the users' identities.

User Dependency on Self-Service

Manual Setup Required: Each user is required to manually link or set up the new OIDC provider through a self-service process.
Scalability Issues: This process is burdensome, especially in large organizations with many employees.
User Experience: Reliance on users for setup can lead to a poor user experience and increased support overhead.

Implications

Authentication Failures: There is a risk of authentication failures or access issues during the transition period.
Not Scalable: Relying on users to perform self-service setup is not scalable for enterprises with a large user base.
Administrative Burden: Administrators lack the tools to ensure a smooth transition and consistent authentication experience.

Describe your ideal solution

Administrative API for OIDC Provider Management

A feature that allows administrators to enable or register new OIDC providers for all existing users programmatically.
Capability to enable or disable OIDC providers on a per-user or group basis as needed.

Seamless Transition Support
Tools to assist in migrating users from one OIDC provider to another without requiring individual action.
Automated processes to associate existing identities with new OIDC providers based on corporate changes.

Workarounds or alternatives

There is no alternative or workaround to do this at this point to my knowledge.

Version

1.3.0

Additional Context