Comments (19)
🦙 Cross-linking to the WebAuthenticationBroker question in the WebView2 repo here
from windowsappsdk.
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?
from windowsappsdk.
@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.
from windowsappsdk.
Have you seen https://github.com/AzureAD/microsoft-authentication-library-for-dotnet ? What additional layers would you want on the client side?
from windowsappsdk.
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 accountsWebAccountProvider
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.
from windowsappsdk.
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.
from windowsappsdk.
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.
from windowsappsdk.
@jonwis Yes checked it about a year ago, it doesn't support custom authentication, i.e. JWT tokens etc.
from windowsappsdk.
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" ?
from windowsappsdk.
@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
from windowsappsdk.
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
from windowsappsdk.
@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.
from windowsappsdk.
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; }
}
from windowsappsdk.
@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)
from windowsappsdk.
can't you write multiple implementations of your interface for different platforms, where the implementation using WebAccountManager is the implementation for Windows?
Probably possible.
- When this issue was written, I wasn't aware of
WebAccountManager
- 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).
from windowsappsdk.
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.
from windowsappsdk.
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.
from windowsappsdk.
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.
from windowsappsdk.
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.
from windowsappsdk.
Related Issues (20)
- WINUI3 Receive another app postmessage exception HOT 3
- MrtCore.PriGen.targets defaults RuntimeIdentifiers to non-portable RIDs - should be dependent on .NET version HOT 7
- Wrong mouse pointer con ContextFlyout open HOT 1
- How to pass package family name in ms-settings uri?
- SatelliteResourceLanguages property is ignored when publishing a self-contained unpackaged .NET app, HOT 2
- Windows.Security.Credentials.KeyCredentialManager.RequestCreateAsync lacks support for Win32 windows, causing the WindowsHello window to not display correctly at the top and failing to authenticate HOT 1
- Provide SystemBackdrop property in AppWindow HOT 1
- Support building / deploying from a Network Drive
- TypedEventHandler no support naot HOT 2
- About how to set the rotation direction of the camera preview control
- Create a PSA app with WindowsAPP SDK
- Resw aka Resources can't be Accessed Between WinUI Based Class Library Projects in Xaml HOT 4
- ResourceLoader can't find resources HOT 5
- Provide a machine readable releases.json with EOL dates
- Main build failure due to missing nuget packages HOT 1
- Inconsistent behaviour of windows App SDK runtime Installer version 1.3
- CheckUpdateAvailabilityAsync crashes when not in debug mode
- [Docs] [Depedency] WinAppSDK app compiles fine but is unable to be deployed - Provide the framework "Microsoft.VCLibs.140.00.Debug.UWPDesktop"
- InAppAcrylicBrush render issue
- WindowsAppSDK-VersionInfo.json: Release.MajorMinor.HexUInt32 is not hex value HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from windowsappsdk.