[WAM integration] UWP + WAM with 3rd party support

Question

[WAM integration] UWP + WAM with 3rd party support

Closed this issue 4 years ago · 19 comments

Is your feature request related to a problem? Please describe.
Today UWP applications can leverage Integrated Windows Authentication when they run on devices/machines which are domain or AAD joined, but they cannot benefit from SSO with the signed-in account when this is a Microsoft personal account (MSA)

Describe the solution you'd like
Be able to have SSO with the signed-in user in Windows 10.
See #599

Describe alternatives you've considered
No good solution today

Additional context

i) How does WAM really integrate into MSAL at a high level? General-purpose broker integration sees the broker as an STS (for ATI - AcquireTokenInteractive, ATS - AcquireTokenSilent) and as an account holder (for GetAccounts, RemoveAccount).

MSAL orchestrates the 2 sources as follows:

ATI - If broker is configured, but not available -> use browser
ATI - with Broker results in a response very similar to EVO's response. Broker generally does not return the RT (iOS is currently an exception). MSAL saves the AT, IDT and Account in its cache for faster processing.
ATS - calls ATS on local cache first and returns if possible. If not, calls ATS on broker (if installed and configured)
GetAccounts - fetches accounts from both broker and local cache. Merges accounts.
RemoveAccount - remove account from both broker and local cache.

ii) How does WAM integrate into other flows? WIA, Device, ROPC?
WAM.AcquireTokenSilent internally will try WIA for you.
WAM could perform ROPC, but I have not implemented this and am not planning to.

iii) ATS with null account -> will login the "current windows user"

Answer 1 · 2019-02-14T08:11:51.000Z

More information about WAM

Conceptual documentation
https://docs.microsoft.com/en-us/windows/uwp/security/web-account-manager

Reference doc
https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication.Web.Core.WebAuthenticationCoreManager

Samples

Answer 2 · 2019-04-15T12:31:25.000Z

Hi @jmprieur
Is there any plan to integrate WAM soon ? Having to choose between Win10 SSO & dynamic consent is very frustrating :)
Any temporary workaround ?
Pascal

Answer 3 · 2019-04-15T13:33:53.000Z

cc: @henrik-me @MarkZuber @bgavrilMS @jennyf19 @trwalke

Answer 4 · 2019-04-15T14:35:41.000Z

Please note that on shared device (like Surface Hub) SSO is a "must have", you can't ask user to log multiple time during a meeting.
As WAM only deliver V1 endpoint token, I don't know how you will be able to make it deliver V2 endpoint token for dynamic consent, but I hope you will find a way to bypass this issue :)

Answer 5 · 2019-04-30T08:49:09.000Z

Bonjour @jmprieur
I'm still looking for a workaround :)
I found that chrome extension Windows 10 accounts is able to inject SSO token in browser request, based on shared service "BrowserCore.exe" that seems to be a UWP AppService.

Do you think that it could be reused to get native Windows SSO Token to inject in MSAL webview ?

If I could contribute in anyway let me know :)

Answer 6 · 2019-07-11T15:17:19.000Z

Hi again @jmprieur :)
Any update ?
Just to mention that it does not affect only MSA : you could have a microsoft organizational account on a machine without AAD joined. Sometimes you want you want to use "invited" microsoft organizational account ona an AAD joined shared PC (like Surface Hub 1 & new Surface Hub 2). In both cases, WAM integration is essential for SSO experience.

Answer 7 · 2019-07-11T15:21:07.000Z

@pfresnay : @MarkZuber is currenlty investigating.

Answer 8 · 2019-10-04T12:07:56.000Z

@jmprieur sorry to request again but I see that @MarkZuber is not investigating anymore and that feature is still delayed to a future release : is there any short time plan to integrate WAM ?
I tried to investigate myself in implementing this feature but it seems that there is some technical limitations in UWP API that prevent any AD v2.0 enpoint scenario with WAM.

Answer 9 · 2019-10-04T12:59:32.000Z

@pfresnay: no worries. You named it: WAM does not support the v2.0 endpoint, yet. This will take some time (there is work to do on the WAM plug-ins side). cc: @henrik-me who knows better all the details.

Answer 10 · 2019-10-04T13:51:47.000Z

@jmprieur thanks a lot for quick answer. If it depends on a WAM change to support v2.0 endpoint, does it means that it will depends on a future Win10 update ? If so, I can forget SSO+dynamic consent scenario on current Surface Hub (no update since 1703) :-( Is WAM this only way to get a SSO token ?

Answer 11 · 2019-10-04T14:03:14.000Z

@pfresnay : can .NET framework or .NET core applications run on a Surface Hub? or can only UWP apps run?

There is a way to get SSO with WAB (the current technology used with UWP):

register as a redirect URI for your application the value returned by WebAuthenticationBroker.GetCurrentApplicationCallbackUri(), which you can retrieve from logs or the debugger.

use .WithDefaultRedirectUri() when you build the public client application:

var app = PublicClientApplicationBuilder.Create(clientId)
                  .WithDefaultRedirectUri() 
                  .Build()

See also https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-client-application-configuration#redirect-uri-for-public-client-apps and

Answer 12 · 2019-10-14T09:31:36.000Z

@jmprieur only UWP apps can run on Surface Hub.
I tried what you suggest but it does not seems to work : AcquireTokenSilent raise an exception because no account provided or login hint does not match any account. (I want SSO, so I don't have any account :-) )

Answer 13 · 2019-10-14T09:33:43.000Z

@henrik-me : do you have any idea on how we can unblock Pascal?

Answer 14 · 2019-10-14T09:58:53.000Z

WAB does support a mode where it achieves a bit of SSO (the browser will pop-up but it will show the previously used accounts).

This is enabled by configuring a redirect URI of "https://sso". I believe this works in ADAL and the experience can be tried out there, but it doesn't appear to work in MSAL.

Answer 15 · 2019-10-14T10:13:45.000Z

It shoud work
I think that @jennyf19 worked on this. It's just that one needs to register a specific URI

Answer 16 · 2019-10-14T11:35:16.000Z

@bgavrilMS I confirm that it does not work with MSAL.
My user scenario: launch a store app with ms-graph experience on Surface Hub.
Current experience:

User login on welcome screen with its credentials
launch store app
app use WAM to get token with SSO.
Works great, but oAuth V1 token negociation => no dynamic consent, that's why I try to use MSAL.
Without SSO, asking user to enter its full credentials again a few seconds after initial login is very annoying, especially when you are starting a meeting.

Answer 17 · 2019-10-14T11:46:28.000Z

Idea: is there a way to build a MSAL IAccount implementation from a WAM "WebAccount" ?

Answer 18 · 2019-12-28T18:29:34.000Z

soooo was builing a new UWP and used the WAM in the past. That was working soo nice 👍

but to be forced back to use MSAL with underlaying the WAB is a major turn off.. 👎 👎 👎

back to a own identity system

Answer 19 · 2020-07-12T00:59:00.000Z

WAMDesktop.zip

This is example how to integrate with WAM. For UWP, even more simpler, you just need to include right namespaces.

WAM uses V1 protocols. For Microsoft services it doesn't matter V1 or V2 tokens, if your service supports only V2 tokens then WAM will return V2 token, however some V2 functionality is not accessible via WAM.

Offices, Teams and many 1st party app use WAM.

For quick test, you can use this client id: 26a7ee05-5602-4d76-a7ba-eae8b7b67941
And resource: https://graph.microsoft.com

For product code you need use your own.