-
Notifications
You must be signed in to change notification settings - Fork 214
Webviews
One important understanding with authentication libraries and Azure AD is the fact that when getting a token interactively, the content of the dialog box is not provided by the library, but really by the STS (Azure AD). The authentication endpoint sends some HTML and JavaScript which control the interaction. Delegating this dialog (this dance) to the STS has many advantages:
- Enabling redirections to other identity providers (for instance login-in with a work school account or a personal account with MSAL, or with a social account with B2C)
- Letting the STS control conditional access, for instance by having the user do multiple factor authentication during this authentication phase (entering a windows hello pin, or being called on their phone, or on an authentication app on their phone). In cases where multi factor authentication is required and the user has not set it up yet, they can even set it up just in time in the same dialog, entering their mobile phone number, and being guided to install an authentication application and scan a QR tag to add their account. This is an amazing experience!
- Letting the user change their password in this same dialog when the password has expired (providing additional fields for the old password and the new password)
- Enabling branding of the tenant, or the application (images) controlled by the Azure AD tenant admin / application owner.
- Enabling the user to consent to let the application access resources / scopes in his name just after the authentication.
- Last, but not least, the password (if one was typed) is never stored by the application, nor the library.
Acquisition of tokens interactively is not available for .NET Core. Indeed, .NET Core does not provide UI components yet (and authentication requires a web browser). If you want to use .NET Core, you probably want to have a look at the Device profile flow (also named Device code flow)
To host the user interaction with the STS, ADAL.NET supports an embedded webview option. For ADAL.NET embedded webview is the only option supported. For all the platforms that provide UI (not .NET Core), a dialog is provided by the library embedding a Web browser control.
Whereas ADAL.NET only supports the embedded browser option, our next generation of authentication library, MSAL.NET also leverages the system web browser for Xamarin iOS and Xamarin Android applications, and you can choose which option to use. For more information, see MSAL.NET uses web browsers.
- Home
- Why use ADAL.NET?
- Register your app with AAD
- AuthenticationContext
- Acquiring Tokens
- Calling a protected API
- Acquiring a token interactively
- Acquiring tokens silently
- Using Device Code Flow
- Using Embedded Webview and System Browser in ADAL.NET and MSAL.NET
- With no user
- In the name of a user
- on behalf of (Service to service calls)
- by authorization code (Web Apps)
- Use async controller actions
- Exception types
- using Broker on iOS and Android
- Logging
- Token Cache serialization
- User management
- Using ADAL with a proxy
- Authentication context in multi-tenant scenarios
- Troubleshooting MFA in a WebApp or Web API
- Provide your own HttpClient
- iOS Keychain Access