Is or will MSAL be compliant with the new RFC 8252 OAuth 2.0 for Native Apps best practice?
It depends. The native applications for iOS and Android, using the new MSAL Preview library, follows this framework for the Browser handling the authentication flow. The Windows .NET library, from the documentation, indicates that it is using something similar to a webview. In iOS, per the documentation:
Calling the acquireToken method results in a browser window prompting the user to sign in. Applications usually require a user to sign in interactively the first time they need to access a protected resource, or when a silent operation to acquire a token fails (e.g. the user’s password expired). Azure AD V2 iOS Getting Started
As for Windows Desktop .Net, that library results in a Window prompt AAD v2 Windows Desktop Getting Started. In Xamarin applications, that will just follow the pattern of the environment, iOS/Android, get the native browser, Windows Desktop will get the Window prompt from the App.
Related
I am working in xamarin.ios native app and I have to authenticate/login with microsoft account to access Microsoft Graph Api or other outlook api. I have done the all settings in Azure active directory, So I have already try to implement this by using xamarin.auth but this is not working due to grant_type parameter is not being supplied and throw an error as invalid_grant and invalid_request.
is any other way to authenticate with microsoft account?
can you help me to implement Microsoft Authentication Library for .NET (MSAL) in xamarin.ios native app. I got some sample xamarin.forms but we need it in xamarin.ios. I am not familiar with xamarin.forms code.
When you use Microsoft Authentication Library for .NET (MSAL.NET) on Xamarin iOS, you should:
Override and implement the OpenUrl function in AppDelegate.
Enable keychain groups.
Enable token cache sharing.
Enable keychain access.
Understand known issues with iOS 12 and authentication.
Having a look at this document : https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-net-xamarin-ios-considerations
We are trying to use the Microsoft Graph Toolkit people picker in a Microsoft Teams tab app we are creating. We are writing the app in angular JS hosted in an Azure Web App.
We don't want to prompt the user for their credentials prior to using the people picker, as the user will have already authenticated to access the Microsoft Teams environment.
Is this currently possible? I've seen some posts about MSAL not being able to silently authenticate when running in an iframe, like when using a web hosted app in Teams. Is this also true for the Teams Authentication Provider?
We have verified that we can silently authenticate using ADAL. A login panel flashes up for less than a second, which is mildly annoying, but fine. Can the Microsoft Graph Toolkit use ADAL for it's authentication? Is there another option we should consider?
Yes, you can use it directly in your teams tab app through teams toolkit extension.
Here is already a graph toolkit people picker sample:
https://github.com/OfficeDev/TeamsFx-Samples/tree/dev/graph-toolkit-contact-exporter
If already have authenticated the user, then you can write your owner auth provider like this one:
https://github.com/microsoftgraph/microsoft-graph-toolkit/tree/main/packages/providers/mgt-teamsfx-provider
I have a website which uses an identity server to authenticate a user, though OIDC, I think. Inside the Xamarin Forms application, I have a facility to log in a user through an identity server via a token.
The website itself uses cookies to handle access tokens which difference to the application. (Note: the website was not written by me). I have so many features to write, so I decided to use WebView to handle those features using React, etc., so I don't need to rewrite the code in native and easy to manage at runtime when people using the application.
What is the logic behind having the mobile application log into the authorized page silently without the user needing to authenticate within the WebView?
Is it possible to handle this scenario?
On Android you can use the CookieManager to add/remove cookies that your private instance of Webview will use.
On iOS, UIWebView has NSHTTPCookieStorage and on the newer WKWebView (11+) you have WKHTTPCookieStore
Google just changed their oauth model to the new specification:
Modernizing OAuth interactions in Native Apps for Better Usability and Security
I am trying to follow (specifically section 7 of) the ietf "draft-ietf-oauth-native-apps-09" linked in the above blog, and also this reference from google:
OAuth 2.0 for Mobile & Desktop Apps
The issue I have encountered is that the custom uri-scheme behavior varies across browsers, and in some cases does not work as expected. In Firefox, which maybe be the default system browser, the app actually open inside Firefox, embedded - it does not return to the app it embeds the app in the browser, while the app from which the authentication flow was started remains open.
In chrome, it correctly redirects back to the app, however the chrome page with the authentication confirmation page remains open and does not close, which could be confusing to users.
How can I make sure that the oauth provider will always redirect to my app (without the browser embedding it), and close the tab or window which had the authentication flow open?
I'm working on a Windows Phone 7 application with C#.
I want to implement my login page using Facebook account. To do that I'm using codeplex Facebook C# SDK.
How can I do that?
Thanks.
You can use ACS for that. See here. (answered your other question too)
In short (assuming you are writing a native app):
Your app (e.g. REST services) trusts ACS. For this you expect a SWT (Simple Web Token) that is issued by ACS
In your app, you embed a web browser that navigates to the app, to ACS and Facebook
Once the token negotiation happens in the browser, you extract the SWT and you pass it to the native app
All subsequent calls to your API include the SWT
If you are writing a "web" app for the phone, then it all just works.
In both scenarios, you would use WIF in your backend. It it is a REST API, you need the OAuth extensions mentioned in the link. If it is a web site, it all works OOB.