You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are many examples for functions that need to authenticate towards external systems on behalf of the user.
For security reasons, application permissions, i.e. permissions that allow the application (here: agent) access to the data of ANY user, are often not desirable and therefore not allowed.
When using delegated permissions, there should typically be an interaction with the user through an OAuth2 flow, i.e. the user should grant access at least once through a web page.
For this to work, there must be a mechanism for an agent function to tell the calling client that an authentication token is required (and with it, it would need to pass information about the url, the requested scope(s), etc.). Once a user authorized access, the token must be fed back into the function.
I create this issue here in the Arc project to trigger the discussion on how a solution would best look like. Arc agents are then only the first step; the other LMOS components will likely have to be adapted as well to smoothly support this flow.
The text was updated successfully, but these errors were encountered:
I think i understand. What the Agent currently does, is return a symbol, such as AUTH_REQUIRED, to the client that picks up the symbol and then performs the OAuth with the user.
The question is, does the Agent need to know about the url, the requested scope(s), etc?
Or is this something the client/app knows?
For a proper modular approach, I would tend to say that the agents need to have the information about the urls - they are the ones that know for what kind of service they require an authentication in order to function. The client/app can get that information from the agents (either as metadata upfront or during runtime) and deal with it accordingly.
There are many examples for functions that need to authenticate towards external systems on behalf of the user.
For security reasons, application permissions, i.e. permissions that allow the application (here: agent) access to the data of ANY user, are often not desirable and therefore not allowed.
A popular example is e.g. the MS Graph API for accessing M365 data, such as e-mails, files or Teams conversations. See the Microsoft documentation for the two authentication methods "delegated" vs. "application" permissions.
When using delegated permissions, there should typically be an interaction with the user through an OAuth2 flow, i.e. the user should grant access at least once through a web page.
For this to work, there must be a mechanism for an agent function to tell the calling client that an authentication token is required (and with it, it would need to pass information about the url, the requested scope(s), etc.). Once a user authorized access, the token must be fed back into the function.
I create this issue here in the Arc project to trigger the discussion on how a solution would best look like. Arc agents are then only the first step; the other LMOS components will likely have to be adapted as well to smoothly support this flow.
The text was updated successfully, but these errors were encountered: