🐛 Bug Report: Entra ID Consent for Azure DevOps Shows Error, despite then working

[sam-cogan]

📜 Description

I'm using Entra ID authentication into backstage, with users auto-populated in the catalog from Entra, and this is all working fine. I am no creating a software template that uses the Git Repo picker and I want it to get a token for Azure DevOps. I have configured the Git Repo picker with the requestUserCredentials option.

When a user first attempts to use this, they are presented with an Entra ID consent page for permission to Azure DevOps, the user consents and then is returned to Backstage where they get an error stating "Login failed, user profile does not contain an email". However, if the user then dismisses the error, everything works and backstage can access ADO as that user.

I have also tried changing the resolver to emailMatchingUserEntityAnnotation and it then complains that Microsoft profile contained no email. I have checked the user entity in Backstage and can see all the appropriate annotations are correct so my only guess at this point is that what comes back from Entra is missing something, but I'm not in control of that, and it doesn't seem to matter anyway, as it all works.

👍 Expected behavior

User should not get any error when completing consent to ADO, given that the access actually works.

👎 Actual Behavior with Screenshots

👟 Reproduction steps

1. Configure a git repo picker to obtain the user secret, and configure it to use dev.azure.com as the domain
2. Attempt to use Git repo picker and get presented with a window indicating login to Microsoft is required
3. Complete consent to allow access to Azure DevOps
4. Get error message
5. Dismiss error and see that all is working as expected

📃 Provide the context for the Bug.

I'm trying to allow the user to perform software template operations using their own ADO credentials.

🖥️ Your Environment

Running locally in docker, and in Azure App Service, both experience the same issue

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

None

[sam-cogan]

Further debugging confirms that the token that comes back from Entra ID does not include the email field, so none of the resolvers will work. I can see the initial login to backstage gets this token, then calls the user profile API in Entra to get the email, but this consent step does not do this. Not sure if the token changed recently to remove email, but if not then I'm unsure how this ever worked.

I've also confirmed with MS that the On-Behalf-Of token issued to the application would never contain the user email, and should be requested via the ID token or similar, the main login process seems to do this, but not the ADO consent.

[Rugvip]

Ah alright, the underlying issue here is that we're taking the shortcut of always signing users in even if we're just doing access delegation via OAuth. This works fine for all providers except for the Microsoft one, just because how particular it is about namespacing scopes and having them be incompatible with each other.

The proper fix on our end is to separate sign-in and access delegation better in the auth backend. We don't have capacity to tackle that just yet though.

For now I'd recommend working around this by using a separate and dedicated microsoft auth provider for sign-in only. You'd duplicate under a separate provider ID in the auth backend, and then set up a custom API in the frontend that is used only by the sign-in page.

[sam-cogan]

Ok, that makes sense. A quick fix for this was to ask for the additional ADO permissions up-front at initial login, this avoids the additional pop-up altogether, but obviously not a great long term solution.

[sam-cogan]

Actually, that didn't work. It now complains about asking for a token with multiple audiences.

I'm not sure I fully understand the proprose workaround, how does a separate auth provider for sign-in help with the the delegation prompt, surely that will still want to sign in again still?