How can you ensure that the OpenID Connect application asked the user what MS365 creds they want to use?

[swinster]

We work in a techy industry where users have multiple MS365 credentials/logins. One issue that we have come across on numerous occasions is that when they attempt to login to Moodle using the OpenID Connect login, it is the cached/current credential that is used to attempt to log in, which is incorrect, but the user is given no chance to select another credential. They are therefore unable to login to Moodle and instead an error will be thrown. This is of course, not great.

How can we ensure that during login, we first check to ensure that the credential that will be attempted to be used is, in fact, the credential that the user WANTS to use?

I workaround is to use another browser or log in to an MS service with the current creds, then sign out, both of which are a bit rubbish.

[swinster]

For example, when a user is signed out of all MS services within a browser session, they will be presented with something like this when then attempt to login into Moodle using the OpenID Connect login, which is great:

However, let's say he had logged into some MS service using the top account in the list, but he needs to login into Moodle using the admin account, now we have a problem. Clicking the same MS365 login button in Moodle now results in:

The user isn't even given the opportunity to use another credential.

In this case, the .com domain is not consented to use the OpenID login on the .net domain (which is actually the subject of another issue outlined in #1438).

[weilai-irl]

Hi @swinster,

This can be solved by specifying appropriate tenant specific authorization and token end points in the auth_oidc plugin settings. The default settings are "https://login.microsoftonline.com/common/oauth2/authorize" and "https://login.microsoftonline.com/common/oauth2/token". The "common" part of the URL means it will try to find valid users sessions from any tenant. If you replace it with the GUID of your tenant, it will only try to find user accounts from the tenant. If your tenant has a custom login page design, it will show as well.

Regards,
Lai

[swinster]

Hi @weilai-irl .

As a temporary fix, we actually updated the "Domain Hint" parameter. in the Moodle Plugin OpenID Connect configuration page, to target our domain.

However, this will need to be used across other MS tenants so one of our own developers suggested we need to use the prompt=select_account parameter (see https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow and https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow). Typically though, this Moodle forum post related to the native Oauth2 plugin (I believe the relevant field is now labelled "Additional parameters included in a login request."), and not the OpenID Connect MS plugin. I think this would solve 99.9% of the issues we see.

How can we add the prompt=select_account parameter to OpenID requests?

[aspark21]

Were likewise interested in this, odd that it isn't default behaviour for the authorize endpoint to prompt the user to login to an account that actually belongs to the tenant rather than give them this screen of text error.

Seems like one can just add this to the authorize endpoint and it just works ?prompt=select_account

Wonder if this should be made more obvious by being a site config setting that would make this more readily usable