Open tomasvanpottelbergh opened 1 year ago
MSNev
commented
1 year ago This has been discussed internally (as part of adding it to the server side SDK's) and there is no secure way of providing the AAD authentication details safely to the browser that could not be compromised.
As such at this point in time this is not an option for the client side focused SDKs.
tomasvanpottelbergh
commented
1 year ago Thanks for the quick reply @MSNev. Maybe I'm missing something, but can't MSAL.js be used to get a token for the user with the required scope? There wouldn't be a need to store any credentials in the code, since the usual browser login flows can be used.
MSNev
commented
1 year ago The AAD token is a "service" token not user based...
And if it was user based there would also be a telemetry "gap" between when the page is loaded and the user becomes authenticated. As the user would need to authenticate against the back-end telemetry server and not the hosting application.
tomasvanpottelbergh
commented
1 year ago I understand that there would be a gap in the telemetry until the user is authenticated, but I think this is acceptable in this scenario.
Regarding the AAD token: is there a technical reason that this needs to be a service token? I am able to assign the "Monitoring Metrics Publisher" role to myself, so why would I not be able to obtain a valid token to authenticate against the ingestion endpoint?
MSNev
commented
1 year ago My understanding is due to the way the back-end validates the token, as mentioned above the user actually needs to validate against the backend so that any credentials are passed along with the request containing the reported event(s) (ie. event payload).
Looking at the examples for the supported languages (.Net, node.js, java and python) all require being provided with the service principal login details or a certificate (this option is not safely possible with browsers). While technical this is what something like MSAL would be obtaining for the current user, I'll need to check with the SDK owners on the exact handshaking required around the client secrets / certificates as from the early discussions this is really how the validation occurs....
If correct, this would mean that you would have to give every user that you want to authenticate via a mechanism like this access to this secret -- thus expanding the possibility that it could get compromised (albeit indirectly as opposed to directly in the web session).
tomasvanpottelbergh
commented
1 year ago I just did a small test and am able to obtain a valid token to call the ingestion endpoint (https://xxxx.in.applicationinsights.azure.com/v2.1/track) using az account get-access-token --scope "https://monitor.azure.com//.default".
I haven't tried doing this using MSAL.js, but I don't see why it wouldn't be possible to obtain such a token in a front-end application, possibly using the on-behalf-of flow?
ggirard07
commented
1 year ago Just received this retirement notice about enforcing Azure AD authentication for application insights by 30 September 2025. Not sure I am following properly though... Does it means Application Insights integration on client side (for a SPA application for example) will no longer be possible at this date? https://azure.microsoft.com/en-us/updates/switch-to-azure-ad-authentication-for-application-insights-by-30-september-2025/
MSNev
commented
1 year ago Clients don't send Live Metrics or any API Keys so this is purely for Server side applications.
Is your feature request related to a problem? Please describe. Application Insights supports disabling local authentication and requiring all telemetry to be authenticated using Azure AD. This authentication is not currently supported by the JS SDK.
Describe the solution you'd like The NodeJS SDK already supports Azure AD authentication. This could work similarly for the JS SDK, with the difference that the identity would be that of a user instead of a managed identity of service principal.
Describe alternatives you've considered A reverse proxy solution as described in #1545 can be used, but this adds a layer of complexity, which is unnecessary when Azure AD authentication already supported by Application Insights.
Additional context Certain front-end applications do not want to expose their Application Insights connection string without authentication. Only authenticated and authorized users should be able to send telemetry in this scenario.