Improve DVLS server Microsoft authentication

Hello Marcel,

Thank you for your feedback. This is a great suggestion and we will look into it to see if we can make the page easier to follow.

Regards,

Hello again Marcel,

We've updated our documentation based on your suggestion.

Regards,

Hello @Emile Simard

Thank you for the update, which looks promising.
A few notes from my side.


Step 8 here is not very clear to me:
Is it to be repeated ? If so, in which case ? If not maybe it needs cleanup.
I think for Delegated rights, we need two different redirect URI's but I might be wrong.


This is not quite correct. If you do not add it here, the first user logging in will be required to do the Admin Consent.
I would rather add those manually, admin consent them and be done with it.


Instead of repeating 3 times "For Delegated permissions" I would add sub-steps for these 3 items and name the main step something like "For delegated permissions only do the following".


Thank you and best regards.
Marcel

Hi Marcel,

I have made the changes you requested. There was indeed a redundancy in step #8, as there is no need to input the redirect URI again, only the "ID tokens (used for implicit and hybrid flows)" checkbox is required for the application permissions configuration. I moved this instruction to step #7 instead, as it makes more sense.

For the "openid", "profile", and "offline_access" permissions, although they do not require admin consent by default, I have modified the box below step #15 for your use case. Thanks for bringing this to our attention, it may help others.

Regards,

Thanks @Emile Simard !
Let's see once we manage a successful delegated rights version if we need to URI's or not.
PS: For now, I can connect it, but not login to DVLS with it.
Marcel

Hello @Emile Simard

Tested: it needs both redirect URI's to work.


Otherwise I get this kind of response.


Cheers.
Marcel

Hi Marcel,

Thank you for the thorough testing and the screenshots — they were very helpful in pinpointing the issue.

You're right that the Delegated permissions configuration, as currently documented, does not work on its own. We've reviewed the configuration and confirmed that your setup with both redirect URIs registered is the working one, so you can keep your environment as is.

We are updating the KB article to correct the redirect URI listed for Delegated permissions, so future readers will get a single, correct value the first time around and won't have to discover this through trial and error.

Émile will follow up once the article is updated.

Thanks again for taking the time to report this — it benefits everyone configuring Microsoft authentication with DVLS.

Best regards,

Hello Marcel,

The article has been updated.

Thanks again for your input,

Hello @Patrick Ouimet and @Emile Simard.

Thanks for your messages.

Please be aware that we need 3 URI's for it to work in 2026.2.7.0.

• User authentication: https://<dvlsfqdn>/dvls /api/external-provider-response
• Connection with service account: https://<dvlsfqdn>/dvls /api/configuration/authentication/azure/connect
• Connection with service account: https://<dvlsfqdn>/dvls/api/configuration/authentication/azure/connect-callback

Best regards.

Hello Marcel,

Thank you for the 2026.2.7.0 redirect URI list, that detail closes the gap we left in the article.

I have confirmed the three URIs you provided are the correct ones for Delegated permissions.

While we are at it, I want to clarify one point so that future readers do not over-configure their Entra app.

The three URIs are required only when you choose Delegated permissions, because the Connect to Microsoft button runs its own OAuth flow on top of the regular user sign-in.
The Application permissions mode (the recommended default) uses the client credentials grant and never hits the connect or connect-callback endpoints, so a single redirect URI (the external-provider-response one) is enough in that case.

The revised KB will split step 7 into the two cases, so this is no longer ambiguous.

On a related note, we are looking into surfacing the exact redirect URIs directly in the DVLS administration UI with copy buttons.
That way, readers will not have to discover them through a doc, and the displayed values will always match the running build.

Thanks again for the thorough testing and the screenshots. This kind of feedback is exactly what makes the documentation better for everyone configuring Microsoft authentication with DVLS.

Best regards,