Client side identity manager

[weitzhandler]

Proposal: Client side authentication manager

Summary

ASP.NET Identity is a magnificent tool to manage identity and authentication in the server side, including integration with EF Core, and is mature enough.

It would be complete, if there would be a client side framework, that knows how to interact with an Identity-enabled server that offers features like:

• User authentication management, via JWT tokens, claims etc.- Integration with Thread.CurrentPrincipal.
• Integration with IHttpClientFactory, to allow generating authentication-clients.
• Module authorization (e.g. add [Authorize(Roles = RoleNames.Admin)] attribute on a ViewModel to only enable it for admins, etc.
• Have some way to get notified when a user has been logged in / out.
• User management API that can easily interact with an ASP.NET Identity server out the box.
• A way of abstraction from UI, so that it can be all handled from the ViewModel.

Rationale

Based on my understanding, Reunion is the largest .NET client-side project, and as such, although not directly a WinUI feature request, is a client-specific feature request in the .NET.

Cross posted from here.

[jonwis]

Have you seen https://github.com/AzureAD/microsoft-authentication-library-for-dotnet ? What additional layers would you want on the client side?

[hansmbakker]

For what kind of .Net client apps are you looking for a solution? Blazor? Mobile? Desktop/UWP?

For UWP there is the combination of

• WebAccountManager lets you use accounts that are known to Windows 10 and lets you use authentication tokens from these accounts
• WebAccountProvider lets you implement the logic for fetching and refreshing tokens for a custom account. It also lets you set sso cookies for use in a browser or browser component.

For Microsoft (personal/work/school) accounts and for certain websites you do not need to implement a custom WebAccountProvider. However if your backend has its own accounts, then those will not work and you might need to write a WebAccountProvider yourself.

Unfortunately, there is no good documentation nor is there a sample maintained by Microsoft how to create a custom WebAccountProvider, so using this technology with custom accounts is not easy.

There is only an unofficial sample, which is helpful but also has some improvement points and the sso cookies functionality seems not to work anymore.

[hansmbakker]

If your website offers OAuth, then you might be able to use https://docs.microsoft.com/en-us/windows/uwp/security/web-authentication-broker as well. However I believe that one does not integrate with the accounts registered in Windows, and it won't offer a "reusable experience".

It won't set SSO cookies for you, it won't register your account with Windows, it won't give other apps the possibility of using the same token logic.

[weitzhandler]

WOW.
Yes I meant mainly UWP. I wish this functionality has been abstracted out of UWP and became a standalone NuGet package, but this is exactly what I was looking for.
Gonna close this issue now.

[hansmbakker]

Glad that it gave you a pointer!

@weitzhandler @jonwis could you please keep this issue open?
The documentation needs to be improved for it to be more useful, and I believe what you said is the idea of this project:

I wish this functionality has been abstracted out of UWP and became a standalone NuGet package

Not sure if this functionality is in scope?

[weitzhandler]

@jonwis Yes checked it about a year ago, it doesn't support custom authentication, i.e. JWT tokens etc.

[jonwis]

Not sure if this functionality is in scope?

Sure! One goal of Project Reunion is bringing some of the Windows Platform functionality initially developed for UWPs over to Win32 applications.

@weitzhandler - So is the feature request then "make the web authentication broker available to Win32 apps" ?

[hansmbakker]

@jonwis I won't speak for the needs of @weitzhandler, but can you please also see what is possible for WebAccountProvider?

• I'm not sure that all functionality that was there still works (sso cookies set by WebAccountProvider app being injected in a browser)
• documentation is suboptimal

[michael-hawker]

🦙 Cross-linking to the WebAuthenticationBroker question in the WebView2 repo here

[bgavrilMS]

We should separate the discussion between UWP and other platforms. For authentication purposes, MSAL.NET (the official Identity SDK) will be integrating with WAM (Windows Auth Manager) directly - tracking work here

[hansmbakker]

@jonwis can you please also see what is possible to improve WebAccountProvider and WebAccountManager and their respective documentation?

I believe the topic of this GitHub issue swerved a few times and was closed/reopened as well - if we need to open separate issues please indicate what issues we need to open and what can be clustered.

[weitzhandler]

@jonwis @hansmbakker

I haven't tried WebAccountManager, but seems to be an adequate solution, given that it can be extended to handle legacy username and password sign-in scenarios (can it?).
However, as far as I understand, WebAccountManager is a UI tool, whereas we want logic for handling the authentication logic from lower levels, such as the ViewModel, which should be agnostic of any UI framework.

If the above is correct, it means that even WebAccountManger, should be abstracted into a lower-level piece that has its independent NuGet package targeting .NET Standard and handles what's not related to the UI, something in the following manner:

public interface IIdentityManager // to be used from VM
{
  IPrincipal CurrentUser { get; }
  IToken CurrentToken { get; }
  Task EnsureLoggedInAsync(); // triggers OnRequestToken

  // awaiting credentials from UI, which can be set into `TokenRequestEventArgs` or whatever it might be
  // and can be using `WebAccountProvider`, or directly against endpoint with username-password
  event EventHandler<object, TokenRequestEventArgs> OnRequestToken;
  
  event EventHandler OnAuthenticationChanged; // i.e. on logged in/out

  // alternatively ITokenProvider which talks to endpoints
  // on either UI (integrated with `WebAccountManager` or VM, or both.
  ITokenProvider { get; } // which can be injected by concrete class' constructor from DI  
}

public class TokenRequestEventArgs
{
  public IToken { get; set; }
}

[hansmbakker]

@weitzhandler can't you write multiple implementations of your interface for different platforms, where the implementation using WebAccountManager is the implementation for Windows?

I understand it would be convenient if that work was done for you (and others of course) though.

Also: WebAccountManager does not show a UI - it is the WebAccountProvider that shows the UI for logging in etc.

The WebAccountProvider logic (can be in the same app or separate app) is activated by calls from WebAccountManager or by calls from windows itself (when users do things on the accounts page in the Windows 10 Settings app)

[weitzhandler]

can't you write multiple implementations of your interface for different platforms, where the implementation using WebAccountManager is the implementation for Windows?

Probably possible.

1. When this issue was written, I wasn't aware of WebAccountManager
2. It would still be great if there was at least a public contract (e.g. Microsoft.Extensions.Identity.Abstractions), with even just interfaces, that any library can implement in a standardized way.

I understand it would be convenient if that work was done for you (and others of course) though.

Yes of course I'd appreciate that, but even if you don't, at least please make an external conventional contract that can be used in the service layer (i.e. VM), that everyone should follow (whether it's UWP, WinUI, WPF or whatever).

[weitzhandler]

@hansmbakker

Also: WebAccountManager does not show a UI - it is the WebAccountProvider that shows the UI for logging in etc.

That's great. Still, both WebAccountManager and WebAccountProvider should both implement IWebAccountManager and IWebAccountProvider respectively, which would be in a lower-level package decoupled from UI, and can be used from the VM/MVU or any other UI-agnostic service-layer. Same is true for CredentialsLocker etc. they were all written in a very UI-coupled manner, assuming they'll be all used from the code-behind or UWP UI service. I might obviously be wrong.

[hansmbakker]

@weitzhandler WebAccountProvider can sit in an app where you implement the interface you want. WebAccountManager does not directly implement your interface but you could wrap it in a service where your interface has multiple implementations.

Frankly speaking I don't expect Microsoft to implement your requested changes soon (I'm not saying it is a bad idea, but I don't see them change these existing APIs), I would recommend the above as a workaround to unblock yourself.

[weitzhandler]

Yup. Sounds good enouh.
I wish I could change my request for MS to create a contract for client-side identity management though.
I'm closing this issue since its title seems to be fulfilled, just not the way I'd want it. Feel free to reopen or lemme know if I should open a new issue elsewhere asking for a bare unimplemented contract.

[hansmbakker]

I'm still asking for better documentation and improvements of these pieces (WebAccountManager & WebAccountProvider). If you're closing the issue, I'll open another one to ask specifically about that.

[weitzhandler]

I've opened this one, which targets my specific scenario.
Maybe in the future I'll open a new one asking for an abstracted contract.