AzureAD scope is hardcoded to Read.All

[OliverKleinBST]

I would like to use the provided Azure Active Directory class to login to my single tenant auth provider. For this I have setup an app registration and provide respective settings. However my enterprise rules do not allow me to use read.all scope but readbasic.all.

Unfortunatly the scope today is hardcoded. My feature request is to make it configurable using some environment variable like AZURE_AUTH_SCOPE.

[jmanhype]

Thank you for reporting this issue regarding the hardcoded AzureAD scope. I understand that you need to use readbasic.all instead of read.all scope due to your enterprise rules. Making the Azure AD scope configurable through an environment variable is a reasonable request that would improve flexibility for different enterprise environments. I'll create a task to implement this enhancement. For tracking purposes, could you share: 1. What specific error messages you're encountering with the current read.all scope 2. Any other Azure AD scopes that might be useful to support This will help us better understand the requirements and implement a more comprehensive solution. In the meantime, as a workaround, you might need to fork the repository and modify the scope manually in your local version. Sent via Lindy <https://lindy.ai>

…

On Sat, Jan 25, 2025 at 4:09 AM ***@***.*** wrote: I would like to use the provided Azure Active Directory class to login to my single tenant auth provider. For this I have setup an app registration and provide respective settings. However my enterprise rules do not allow me to use read.all scope but readbasic.all. Unfortunatly the scope today is hardcoded. My feature request is to make it configurable using some environment variable like AZURE_AUTH_SCOPE. — Reply to this email directly, view it on GitHub <#1804>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANMI52EO3MFGFDGAA4MWAYL2MNPGRAVCNFSM6AAAAABV3GM7U6VHI2DSMVQWIX3LMV43ASLTON2WKOZSHAYTAOJQGM2TAMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[OliverKleinBST]

Thank you for reporting this issue regarding the hardcoded AzureAD scope. I
understand that you need to use readbasic.all instead of read.all scope due
to your enterprise rules.

Making the Azure AD scope configurable through an environment variable is a
reasonable request that would improve flexibility for different enterprise
environments. I'll create a task to implement this enhancement.

For tracking purposes, could you share:

1. What specific error messages you're encountering with the current
   read.all scope
2. Any other Azure AD scopes that might be useful to support

This will help us better understand the requirements and implement a more
comprehensive solution.

In the meantime, as a workaround, you might need to fork the repository and
modify the scope manually in your local version.

Sent via Lindy https://lindy.ai
…

1. I get HTTP Error 400 when trying to use a scope that is not granted (admin approval required). In my case admin grant exists only for User.ReadBasic.All and not for User.Read. When I clone chainlit and change in class AzureADOAuthProvider(OAuthProvider) from "scope": "https://graph.microsoft.com/User.Read" to "ReadBasic.All" (without graph url) it works.
2. ideally the scope can be set via a configurable environment variable, so that there is full freedom. Typical use cases for me on top of the ReadBasic.All are "api:/myownscope" or also "openid profile".

[jmanhype]

Thank you for providing those details. This helps clarify the issue significantly. Based on your feedback, I understand that we need to: 1. Fix the current implementation where: - The hardcoded User.Read scope causes HTTP 400 errors when not pre-approved - The Graph URL prefix needs to be handled properly for different scope types 2. Add configuration flexibility to support: - Microsoft Graph API scopes (e.g., User.ReadBasic.All) - Custom API scopes (e.g., api:/myownscope) - OpenID scopes (e.g., openid profile) I'll update the issue to propose implementing an AZURE_AUTH_SCOPE environment variable that accepts a space-separated list of scopes, with the Graph API URL prefix being automatically added only for Microsoft Graph scopes. Would you be interested in contributing this change via a pull request? If not, I'll work on implementing this enhancement. Sent via Lindy <https://lindy.ai>

…

On Sat, Jan 25, 2025 at 6:51 AM ***@***.*** wrote: Thank you for reporting this issue regarding the hardcoded AzureAD scope. I understand that you need to use readbasic.all instead of read.all scope due to your enterprise rules. Making the Azure AD scope configurable through an environment variable is a reasonable request that would improve flexibility for different enterprise environments. I'll create a task to implement this enhancement. For tracking purposes, could you share: 1. What specific error messages you're encountering with the current read.all scope 2. Any other Azure AD scopes that might be useful to support This will help us better understand the requirements and implement a more comprehensive solution. In the meantime, as a workaround, you might need to fork the repository and modify the scope manually in your local version. Sent via Lindy https://lindy.ai … <#> 1. I get HTTP Error 400 when trying to use a scope that is not granted (admin approval required). In my case admin grant exists only for User.ReadBasic.All and not for User.Read. When I clone chainlit and change in class AzureADOAuthProvider(OAuthProvider) from "scope": " https://graph.microsoft.com/User.Read" to "ReadBasic.All" (without graph url) it works. 2. ideally the scope can be set via a configurable environment variable, so that there is full freedom. Typical use cases for me on top of the ReadBasic.All are "api:/myownscope" or also "openid profile". — Reply to this email directly, view it on GitHub <#1804 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANMI52BEV2R7X6KSNQGCLN32MOCGFAVCNFSM6AAAAABV3GM7U6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJTHE2TMNBWGM> . You are receiving this because you commented.Message ID: ***@***.***>

[OliverKleinBST]

Thank you for providing those details. This helps clarify the issue
significantly.

Based on your feedback, I understand that we need to:

Fix the current implementation where:

• The hardcoded User.Read scope causes HTTP 400 errors when not
  pre-approved
  • The Graph URL prefix needs to be handled properly for different
    scope types

Add configuration flexibility to support:

• Microsoft Graph API scopes (e.g., User.ReadBasic.All)
  • Custom API scopes (e.g., api:/myownscope)
  • OpenID scopes (e.g., openid profile)

I'll update the issue to propose implementing an AZURE_AUTH_SCOPE
environment variable that accepts a space-separated list of scopes, with
the Graph API URL prefix being automatically added only for Microsoft Graph
scopes.

Would you be interested in contributing this change via a pull request? If
not, I'll work on implementing this enhancement.

Sent via Lindy https://lindy.ai
…

I would prefer not to contribute via pull request myself.

[jmanhype]

No problem at all! I'll take care of implementing this enhancement. I'll work on adding the configurable scope functionality and make sure it properly handles all the different scope types you mentioned. I'll keep you updated on the progress through this issue. Thank you for bringing this to our attention and providing such detailed information about your requirements. Sent via Lindy <https://lindy.ai>

…

On Sat, Jan 25, 2025 at 6:53 AM ***@***.*** wrote: Thank you for providing those details. This helps clarify the issue significantly. Based on your feedback, I understand that we need to: 1. Fix the current implementation where: - The hardcoded User.Read scope causes HTTP 400 errors when not pre-approved - The Graph URL prefix needs to be handled properly for different scope types 2. Add configuration flexibility to support: - Microsoft Graph API scopes (e.g., User.ReadBasic.All) - Custom API scopes (e.g., api:/myownscope) - OpenID scopes (e.g., openid profile) I'll update the issue to propose implementing an AZURE_AUTH_SCOPE environment variable that accepts a space-separated list of scopes, with the Graph API URL prefix being automatically added only for Microsoft Graph scopes. Would you be interested in contributing this change via a pull request? If not, I'll work on implementing this enhancement. Sent via Lindy https://lindy.ai … <#> I would prefer not to contribute via pull request myself. — Reply to this email directly, view it on GitHub <#1804 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANMI52AJRYCIJSLBVCQLEAT2MOCNXAVCNFSM6AAAAABV3GM7U6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJTHE2TMOJVGE> . You are receiving this because you commented.Message ID: ***@***.***>