Users can't change email address in account (reopened)

I don't see anything in the code that'll update the e-mail address at the IDP, or am I missing something?

I think we need to either:

• Send data there after we update it in Drupal, or
• Direct users to the IDP to change their password there (and then update Drupal)?

The latter probably makes more sense because we want to do that first as it's authoritative (and may have its own rules), and then only update Drupal if it happens over there.

After further thought (and looking into how Auth0 can support this, or rather doesn't as there's no user-facing front-end for it), I think we need to go with a third option, which includes the following:

• If the IDP's plugin implements the necessary method for making the change at the IDP:
  1. Allow the change in Drupal (with the work done already), and then
  2. Make the change at the IDP.
• Otherwise,
  1. Prevent e-mail address changes by greying out the field

So we'd need a new method called something like updateUserEmailAddressAtIdp() in OpenIDConnectClientBase. If the plugin in use doesn't implement it, it won't be possible for users to change their e-mail addresses.

But how do we verify the new e-mail addresses? 🐛 Use email verification when changing user email addresses Needs work isn't in yet, and we'd need to depend on another contrib module if we go with Email Confirmer → . Maybe we should simply document that one of these options, either a core patch or the contrib module, is recommended, and leave it at that.

A Drupal user account that gets provisioned through any OpenID client should be considered a federated member. Thus, the Identity Provider (IDP) which provisioned the user should be considered the canonical source for the member's data. Any updates to the member's data should be done on that platform.

In order to allow for changes to account data within Drupal, I believe a federated member should disconnect their IDP and then follow a password reset process.

I am in support of disabling the member's email/password fields in these situations. We could probably take it a step farther and provide an action that disconnects them from their IDP and then initiates a password reset to the email stored in the Drupal user account. Then, they could change their password and reconnect to an IDP if they chose.

As for updating an IDP with updates in Drupal: I do think it would be possible to bubble account changes from Drupal back up to a trusted IDP through an API request, but I believe that is a pretty specific requirement and should live in a projects custom code. There are too many variables at play with too many different API requests for it to live here.