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.
Related
In our project we've built an Azure Function which launches Puppeteer in headless mode, goes to our webpage and takes a screenshot of the page which is then emailed out as pdf report. Works locally and deployed to Azure. That was the POC though. Now, we're moving to production and introduced authentication (Azure AD B2C, single tenant), will run each http request via APIM etc.
What happens now:
our Function app was registered in AD as a daemon and receives an access token.
this access token is inserted into 'Bearer ' Authorization header in Puppeteer (page.setExtraHTTPHeaders)
headless browser does not get authenticated and screenshot we receive is of the login screen (Azure SSO)
What needs to happen
we need to convince the react-msal library our FrontEnd is using to authenticate users, that the headless browser should get authenticated and allowed to render the page
The solution I've come up with so far is to replicate msal-react's logic of saving session information into Puppeteer's session storage, so that when msal-react checks for persisted session it will find it and allow headless chromium in. I'm yet to implement it. I'm curious if anyone in the community has experience building something similar.
I have the following access policy configured that should blocks access to Microsoft Teams, if there is no valid client certificate:
This policy works in the browser, when teams.microsoft.com is opened (including logging in with valid crendetials) with the custom error message:
Yet, while using the Teams Desktop App, the affected user can login and use teams even without the certificate. The message in the Activity Log of Microsoft Cloud App Security states "bypass session control".
How does the rule not affect the Teams App but work in the browser.
The teams app cannot have access to a certificate, because I tried it in a Sandbox.
As well as the bypass info must mean, somewhere a bypass is allowed/configured? But where would I find that?
If you extend the policy to also check the Client App both for Browser and App, then also the Teams App will be blocked by the policy (or not if the certificate is available).
• You are able to access Teams client app on desktop because you have not selected filters that include ‘client app equals to Mobile and Desktop’ in Access Control Policy as below.
• So, once you select the filters as per your convenience, as above, and the actions to take as ‘block’ or ‘test’, the desktop teams will not be able to start up. Also, the ‘bypass session control’ message in the browser while accessing a blocked or restricted site is displayed in activity logs in Microsoft cloud app security because you might be having ‘admin’ level access to modify, create or delete any access control or session control policy in there.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/cloud-app-security/manage-admins
https://learn.microsoft.com/en-us/cloud-app-security/troubleshooting-proxy
I have a Blazor server application with JWT authentication. The application authenticates using a JWT token in the URL. The applications runs successfully in debug mode under localhost locally without any issues.
When published the application to Azure service the following happens:
Go to google or any website
Paste url with token
It doesn’t validate the token and redirects to the error razor page
Paste same url again and it works completely fine and loads correctly
As it’s not happening in debug mode on visual studio not sure on the best way to debug this? Or why this could be happening?
You could have an issue with CORS? Does it work if you go through the normal authentication flow on the app? E.g., using incognito browser, open Azure app, you are unauthenticated so you get redirected to login, after login you get redirected to app again?
If that works, you are having issues with where the request is coming from (possibly). There really isn't much info to work with here - can you update with browser Developer Tools console output/network tab and then the server logs?
So I'm working on a project to redeploy an application that was previously hosted as an Azure Mobile Service as an Azure Mobile App. Said application has a frontend (hosted as a Web App in Azure) and backend API (this is the Mobile App) that is called directly from the frontend's javascript. The upgrade had been going well up until I started working on the Microsoft Account Authentication piece. Following the instructions at...
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-net-upgrading-from-mobile-services
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-microsoft-authentication
...got things mostly rolling. My application has been registered in the Microsoft Account Developer Center, I specified a Redirect URI following the 'https://{{my_backend_mobile_app_name}}.azurewebsites.net/.auth/login/microsoftaccount/callback' format, I configured the Microsoft Authentication/Authorization in the appropriate blade of my mobile app in Azure using the ClientId/Secret from the Microsoft Account Developer Center. Things go mostly well when I test it out: I can go to the frontend of my application and click on the 'Sign In' button, a new window opens with Microsoft's Login.Live site where I am prompted to login with a Microsoft account, I do so successfully and am redirected to the Redirect URL specified in the Microsoft Account Developer Center and it has Code and State values appended in the query string.
However, the page that is shown when I get redirected there is a 'You do not have permission to view this directory or page'. If I copy the URL, open a new tab, paste it in and hit enter it takes me to a 'You have successfully signed in' page. But neither way takes me back to the frontend of my application where it would log me in and continue into the site as everything is still happening in the new window that was opened for signing in. If I close that window, the authentication process sees that as a 'Cancelling' of the login and requires me to login again (which just repeats the above process). If I leave the window open and go back to the window with my frontend site, it is still waiting for a response from the login process.
So this leads me to my main question: How do I get the Microsoft Account Authentication process to actually return the login response to my frontend site rather than to the login window?
Side note, I've updated the SDK's for both the frontend and backend from the Mobile Service ones to the Mobile App's ones. In doing so I had to add in an OWIN middleware (per the instructions in link #1 above, under the 'Updating the server project' header) to my backend app. My current hypothesis is that this OWIN middleware isn't configured correctly for authentication and is getting in the way blocking the callback from working properly; thus, I am messing around with the app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()); piece.
According to your description, I assumed that you are using the JavaScript client library for Azure Mobile Apps. I checked this issue on my local side and found I could encounter the same issue as you mentioned as follows:
Then I tried to deploy it to azure web app (https://brucechen-mobile.azurewebsites.net/login.html), I found it could work as follows:
After searched the web I found a similar issue and refer to this blog about Fix the Ripple Issues. I log onto azure portal and choose my mobile app, then click "All Settings > CORS", add the URL for my local web application as follows:
Then, click "SETTINGS > Authentication / Authorization", add the ALLOWED EXTERNAL REDIRECT URLS as follows:
Based on the above settings, it could work as expected on my local side as follows:
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/