Appcenter: Methods for Custom Native Authentication

[SOliasS]

At the moment i am not aware of an option where you could create a custom native Login/Register/Authentication etc. with Azure Active Directory B2C.
But for the consistent experience it is necessary to be able to fully create the authentication UI in xamarin forms(or any other plattform).
Cognito implemented this by offering functions to call to register/login/authenticate etc.
For Azure Active Directory B2C it would be cool if you could deactivate the WebUI for the Userflows and just call some Method in code.

Auth.SignInAsync(customLoginPage);
or
Auth.CustomRegisterInAsync(string email, string name, string password);

Alternative: Just use Cognito and wait till its an authentication option

Also the complete experience with creating a new Azure Active Directory B2C is really tedious for Developers who don´t have experience with Azure and could be streamlined with a default option which initializes everything according to a standard config.

[Jjagg]

~I need this to make AppCenter's Auth a good solution for my project. For users, getting sent to a website to sign up/in for a mobile app is not a good experience. Because Auth fuels a lot of the other functionality of AppCenter, this might be a blocker for me for using AppCenter altogether.~

~Since the B2C web pages can be fully customized (albeit with HTML/CSS/JS), if they could be wrapped in a webview so it can be made to look native that might also be workable, though the latency for showing the page is an issue. A fully native solution would be way better.~

~EDIT: I read up and found out you need the browser to actually handle things (though I don't understand why). So the ability to wrap the login page in a native webview and to check if the current user has a valid token already might be the next best thing. Then I can make the UI look native and load the page in the background and show it when it finishes loading. So I think that fixes both the native look and latency issues.~

~EDIT2: msal supports using System WebView (and can fall back to embedded WebView), so I think it's possible to use that from AC.Auth.~

I read some more, and in short there's two things that I would like to have to completely solve my problems with AC Auth:

• support forcing System WebView with embedded WebView fallback in msal
• API to check if user is logged in or API for silent login (that fails if user is not already logged in)

[Oddj0b]

Sorry @SOliasS, this has fallen through the cracks I believe @amchew can help you out.

[amchew]

Hey @SOliasS, thanks for sharing your use case, I contacted you via email to schedule some time to speak on Mon to understand more.

@Jjagg would love to learn more as well. Would you be free to chat next week? Email me at amchew [at] microsoft [dot] com if you're keen!

[amchew]

Hey both, thanks for responding to me, and looking forward to chatting with you next week!

[Jjagg]

Hey @amchew! Any update on this?

[Jjagg]

Sorry for pinging you again @amchew, but I'm curious if you have an update for us.

[amchew]

Hey @jjagg, apologies for the late reply, and not at all! :)

I just proposed a work item to create an SDK method that will accept any AAD B2C user flows or custom policies, and you'll be able to pass the "signin with ROPC" policy to App Center for your user scenario (to sign users into the app natively) to work. The work item is currently in "ready for work" on our backlog, and should get picked up soon. Will continue to keep you updated.

[SOliasS]

@amchew do i understand that right?
"signing with ROPC" will enable us to create user flows directly in the App, with completely native UI?

[Jjagg]

Thanks @amchew!
It's nice to have a native UI, but there are some security concerns with ROPC and it seems to be discouraged for new applications:

• From the OAuth2 spec:

The resource owner password credentials grant type is often used for
legacy or migration reasons. It reduces the overall risk of storing
usernames and passwords by the client but does not eliminate the need
to expose highly privileged credentials to the client.

This grant type carries a higher risk than other grant types because
it maintains the password anti-pattern this protocol seeks to avoid.
The client could abuse the password, or the password could
unintentionally be disclosed to an attacker (e.g., via log files or
other records kept by the client).

Additionally, because the resource owner does not have control over
the authorization process (the resource owner's involvement ends when
it hands over its credentials to the client), the client can obtain
access tokens with a broader scope than desired by the resource
owner. The authorization server should consider the scope and
lifetime of access tokens issued via this grant type.

The authorization server and client SHOULD minimize use of this grant
type and utilize other grant types whenever possible.

• Blog: Why the Resource Owner Password Credentials Grant Type is not Authentication nor Suitable for Modern Applications

Therefore I would still be interested in a method of customizing the browser view for the sign up and sign in flow. Something like Xamarin.Auth's GetUI to retrieve the native web view object so it can be casted and customized for the target platform. It seems to me like that would take less effort to implement. With the B2C web page customization and mobile app client control over the webview we can stick with the more secure flows while having control over the look-and-feel (limited only by what the platform supports for customizing the web view).

"signing with ROPC" will enable us to create user flows directly in the App, with completely native UI?

@SOliasS yes, this is correct.

[SOliasS]

@Jjagg Sure ROPC is not the most desirable authentication for security reasons(as you have to trust the developers that they are able to keep your info save), but it's a basic feature that the user expects, as many don't want to connect their accounts with/or just don't have a supported account.
Also the implementation here is always with the ad b2c azure component in the background.
Which includes the basic security features,(so no saving user data unencrypted on public servers etc.).

As there will be support for Custom policies you should be able to customize the Webview to you liking(even for specific operating systems). You are also already able to completely the default screens, but you would have to host the Webpages.

The only thing that might be missing(as i interpret), is that you can't open the Webpages(if you are using the AD b2c web login or the login for custom Identiyprovider like google) in the Application Webview. But as these Webviews aren't always the best implementations of a browser, so i personally think there might be some problems(Feature support/Security) when trying to use them for theses tasks.

[Jjagg]

I don't think it's a bad thing that ROPC will be supported, but it would be nice to additionally be able to customize the webview on the app side for the Sign in/up flow.

But as these Webviews aren't always the best implementations of a browser, so i personally think there might be some problems(Feature support/Security) when trying to use them for theses tasks.

Using webviews takes managing user credentials out of the hands of the client application. That is good for security. The blog post I linked in my previous comment lists additional benefits, with regards to security as well as UX (e.g. tokens shared with browser, password manager integration).

[SOliasS]

With webviews i thinking of something like:
https://docs.microsoft.com/de-de/xamarin/xamarin-forms/user-interface/webview?tabs=windows
Which is as far as i know an implementation of a "Webrowser" which is developed by Xamarin.
On Android it's based on Chromium, on iOS i don't know.
But it's only a basic implantation and therefor might not include all CSS features or HTML5 security implementations.
Which could possibly introduce problems to the process which wouldn't happen on a normal browser.
In addition you could customize the implementation and potentially introduce vulnerability into the browser.

Also i don't see how "tokens shared with browser" would be possible with this implementation.

But honestly i haven't used the included Webview too much and i'm no security expert ;)

[Jjagg]

Under the hood Xamarin's webview uses implementations provided by the operating system. On Android it uses WebChromeClient, on iOS it uses WkWebView. Those are full browsers.

However I want to be able to use the system webview, meaning Chrome Custom Tabs on Android and SFSafariViewController on iOS. Those are essentially embeddable versions of a Chrome or Safari tab. The client app can't tell what goes down inside those views. They share cookies and website data with Chrome and Safari. It's possible to customize how those views are shown in your app, but you can't touch the content. Xamarin.Auth shows exactly what I want, it exposes the native UI object that's created for a sign in/up flow: https://github.com/xamarin/Xamarin.Auth/wiki/Details#2-creatingpreparing-ui.

[SOliasS]

@Jjagg ok, i wasn't aware that this was possible...
You're right, this would definitely be nice for the Web Part...

[SOliasS]

@amchew any updates?

[SOliasS]

1621 Auth is dead