Azure Mobile Services authentication with WinJS - winjs

I started a Universal app with WinJS 2.0 for a Windows (and Phone) 8.1 project, and went through the tutorial to register my app for authentication and configure Mobile Services with the Client ID and Client secret. But now how do I actually handle a login with a Microsoft account on my application? I can't find any examples of how to do this anywhere...am I missing something?
I know Mobile Services is working on my application because I am able to do an insertion into a table with it.

On your client object, call:
client.login('microsoftaccount').done(function (result) {
// handle successful login
}, function (error) {
// handle failed login
});

Related

Unable to run tab on MS Teams Desktop App

I have build Tabs for MS Teams and showing me this error on the desktop app only as seen below
Also, this is working fine on every other platform (Browser, Mobile app)
InteractionRequiredAuthError: AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in a different IE security zone than the Azure AD endpoint (login.microsoftonline.com). Trace ID: f6450045-e435-4fa7-8dcb-b1e7da7f2300 Correlation ID: b88afb3e-7b95-48fc-a68e-5875238dd1d3 Timestamp: 2021-01-28 08:56:59Z
Here we are using MSAL, silent authentication.
const tokenRequestObj = {
scopes: ["user.read"],
loginHint: loginHint,
};
this.msalService.acquireTokenSilent(tokenRequestObj) //get silent token using context.
.then(async authTokenResult => {
console.log(authTokenResult); //Got access token.
}).catch((error) => {
if (error.name === 'InteractionRequiredAuthError') {
this.msalService.acquireTokenRedirect(tokenRequestObj)
}
});
this.msalService.handleRedirectCallback(this.authCallback);
It's not a bug, it's a feature.
=========== You can scroll down to the solution section ================
This is a boring section...
So let me try to explain what is happening on the background.
First you call msalService.acquireTokenSilent which does some magic on the backgroung, something similar to this:
Checks localStorage for a token you can obtain. (Web App level).
Invokes MSTeams App Api and trying to get token from there. (Teams App level).
Reqests token from Graph (Network level).
If the background magic doesn't work it means you have to sign user in and obtain token from the OAuth. That's why you see this error:
InteractionRequiredAuthError: AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in a different IE security zone than the Azure AD endpoint (login.microsoftonline.com). Trace ID: f6450045-e435-4fa7-8dcb-b1e7da7f2300 Correlation ID: b88afb3e-7b95-48fc-a68e-5875238dd1d3 Timestamp: 2021-01-28 08:56:59Z
Next you call msalService.acquireTokenRedirect which redirects user to login.microsoftonline.com and here's where the things go wrong!
You see, Teams App works in a different way on different platforms. There are 4 platforms: IOS, Android, Web, Desktop.
IOS - opens Tab/Task in webview, has no redirect limitations.
Android - opens Tab/Task in webview, has no redirect limitations.
Web - opens Tab/Task in iframe, has redirect limitations (X-Frame-Options).
Desktop - opens Tab/Task in iframe, has redirect limitations (X-Frame-Options). Well basically Desktop is the Electron app which hosts Web app. But it has popup limitation which i'll desctibe below.
The issue you are facing with is related to the Desktop platforms.
======================= The solution section ===========================
So here's what you should do to fix this:
Implement redirects for mobile platforms only.
Avoid redirects on Web/Desktop platforms and use msalService.acquireTokenPopup instead.
Desktop App doesn't open popup window (Why Microsoft, just why?) instead it deligates it to a default OS browser (that's the limitation i wrote above). So you have to handle it on your own.
Here's an example how to handle Desktop popup issue:
Make a session on the backend.
Connect to the backend's session from Desktop App via websocket.
Wait for a data from websocket.
Send data to the websocket from the redirectUri page (in the OS web browser) when user is successfuly signed in and redirected.

Azure AD B2C Single Sign Out

I have two web apps, one a .Net Framework app and the other a .Net Core app. Both are registered with the same B2C environment.
They interact with one another such that when I sign in on one application, when I click on sign in on the other, this takes me past the input screen and logs me in with the credentials already entered on the other application.
The issue I have is that I have set up a Logout Url for both applications, but it is only working one way round and not the other.
If I am logged in on both applications, then sign out of the Framework application, then when pressing F5 on the Core application, the user is logged out as expected.
However, if I try this the other way round. So I sign out of the Core application, then press F5 on the Framework application, then this does not log the user out.
As it is working one way but not the other, I assume this must be an issue with how the Framework application is setup and not with how the Custom Policy files linked to each application are setup, as if it was, then neither would work?
In the B2C application setting for the Framework application, the Logout URL is:
https://xxxx.azurewebsites.net/Account/SignOut
Which points to:
public void SignOut()
{
if (Request.IsAuthenticated)
{
IEnumerable<AuthenticationDescription> authTypes = HttpContext.GetOwinContext().Authentication.GetAuthenticationTypes();
HttpContext.GetOwinContext().Authentication.SignOut(authTypes.Select(t => t.AuthenticationType).ToArray());
Request.GetOwinContext().Authentication.GetAuthenticationTypes();
}
}
I've also tried an endpoint which is the same as the above but doesn't check if the user is currently authenticated, and just runs the three lines without the if check, but that doesn't work either.
While, the B2C application settings for the Core application, the Logout URL is:
https://yyyy.azurewebsites.net/AzureADB2C/Account/SignOut
Any ideas?

How to handle simple authentication with Azure (with local user accounts)?

I would like to build a very simple Angular 4 app with a WepApi Service as backend.
I would also like to have users register with my app (the basic "create user" - "validate email" - "log in" workflow).
The user/passwords should be stored with my own app (SQL database).
Where would I go for this very basic information? I am highly frustrated with all the "look it's so easy, you can use ANY social media account! Facebook, Twitter, Google, Microsoft! Just three clicks and all is super-secure with OAuth" talk.
Please point me in the right direction - finding this very basic information seems impossible to me.
what i have done is :
Step 1 : call facebook auth from client it returns me id,
profile etc,
Step 2 : then I send fb id to the server (deployed on azure), where it
checks if this fb id already exists in database it redirects to login,
otherwise it creates a new user
you can also authenticate fb token on server side also for more security.
for login with facebook scenario this question might help you.
I would recommend you to use Azure App Service along with Easy Authentication as it allows you to configure your app along with Facebook/Twitter/Google/MSA.
For Starters see this:
How authentication works in App Service
How authorization works in App Service
The following tutorials show how to configure App Service to use different authentication providers:
How to configure your app to use Azure Active Directory login
How to configure your app to use Facebook login
How to configure your app to use Google login
How to configure your app to use Microsoft Account login
How to configure your app to use Twitter login
The above steps do not require you to write any code. However if you need to authorize then you need to handle that in your application.
The above should get you started. Also see this thread where I shared insights on how you can query Facebook: Correct Facebook Graph Api Video Insitghts Request PHP SDK
I also have a blogpost on this here:
Azure App Service: Using Easy Auth to query Facebook information via Graph API

Which Google Oauth 2.0 Client ID type choose for cordova hybrid mobile apps?

I am developing cordova based hybrid mobile apps targeted for android and iOS smartphones.
Usecase: The application authenticate user and then would be accessing Google Calendar API's, and finally display user events on the app.
Note: I will be Using 3-legged OAuth and Google Data APIs without the client libraries.
Question
The Cordova-enabled WebView provides the application with its entire user interface, so what should be the application type in this case?
Since everything is going inside webview, so Shall I choose "Web Application"?
OR
Do I need to create seperate Applications type for Android and iOS
seperately?
Or can iOS Application Type work for both Android and iOS?
Please suggest what should be the proper approach to choose application type in this case.
Thanks!
It depends on how your app is setup. If you plan on handling all of the OAUTH processing on a backend server then you can use the Web application type, and you can have all the OAUTH work offloaded to the backend server.
If you do not have a backend server and will do all OAUTH processing on the user's device, then you should create both an iOS and Android client ID. For example:
https://github.com/EddyVerbruggen/cordova-plugin-googleplus
This plugin's documentation shows the creation of both an iOS and Android client ID to enable Google Sign In on a Cordova app.

Authorising a .net user-application through Google or Twitter

My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/

Resources