Replies: 8 comments
-
Sometimes we need to access multiple different APIs, and they each need their own token with the correct audience and scopes. In addition to, (or instead of) the |
Beta Was this translation helpful? Give feedback.
-
I say lets not reinvent what's already out there and provided by Microsoft. I believe we should be providing guidance on how to use ARC alongside other common libraries such as @microsoft/mgt that provides a really nice SSO componennt that can easily be placed within the user slot of the The providers can also be used seperatly from the Microsoft components so I think we might be able to use the MSAL2 provider under the hood to handle auth for the |
Beta Was this translation helpful? Give feedback.
-
@thomasmarr The |
Beta Was this translation helpful? Give feedback.
-
@jasperwieringa the challenge is when we need (after authenticating) to request access tokens for other APIs, i.e. with different scopes from those used in the login request. If getAccessToken on arc-sso allows for the user to pass the options permitted by the MSAL acquireToken method that should work. If it just re-uses the scopes array passed to the component for logging in, then not really. From what I can tell, the arc-sso component is really trying to create an abstraction on top of MSAL, to make it quick and easy to add SSO with sensible default behaviour. I think this GitHub issue is really stemming from a need for sufficient escape hatches to be provided to give us access to the underlying MSAL objects / methods when we need them. |
Beta Was this translation helpful? Give feedback.
-
The abstraction level is indeed an important factor of any ARC component. |
Beta Was this translation helpful? Give feedback.
-
My personal view is that on something like this, ARC should just give as much access as possible to the underlying MSAL stuff. With the design oriented components, deciding what constraints to apply in order to 'enforce' alignment with the design system is totally valid. But for something like auth I struggle to see a good reason not to give the user as full control over it as possible (but with sensible defaults to make the most common use case as easy as possible). I don't think it's really the design system's job to restrict how people handle implementation of auth. |
Beta Was this translation helpful? Give feedback.
-
I definitely agree. The only 'problem' or point to consider is, web-components are accessible by users of your application. Example: Although this might not necessarily cause any real problems, it is still something to consider/be aware of. |
Beta Was this translation helpful? Give feedback.
-
Would allowing the |
Beta Was this translation helpful? Give feedback.
-
Currently the ARC SSO component handles authentication which works really well. Internally when the component retrieves the avatar photo, it uses a private function
_getAccessToken
to retrieve the access token required to call the Microsoft Graph API endpoint.If an application that utilises the ARC SSO component needs to call another Microsoft Graph API endpoint, there is currently no way to retrieve the access token (other than potentially through local storage). It would be great if we could make the access token available to applications.
I propose we do this in one of two ways:
_getAccessToken
function publicly availableBeta Was this translation helpful? Give feedback.
All reactions