We have a React App which is hosted inside an ASP.NET Core site hosted on an IIS Server.
Originally we had the React App hosted on its own in IIS and protected by HTTP Basic Auth on our Staging server. This worked fine.
We then moved to hosting the React App inside the ASP.NET Core site. This has now caused problems with Basic Auth. If the user enters the site through just the domain they can authenticate with Basic Auth and everything works. However is the user refresh a page in their browser, the Basic Auth header is no longer sent and causes the server to challenge the user again for their username and password. For our testers this makes their lives very hard.
We have reproduced this in both Firefox and Chrome.
Using Fiddler we are able to request the pages/documents directly with the Basic Auth header, so we know that direct access is possible. We just don't understand why the browser is removing the header on a refresh.
IIS basic authentication is not cookie-based authentication. client just send user credential to client side with authorization header. It looks like the fresh page action will clean the cache or override that header. Please check this on other web browser like edge or IE.
Related
We are having problem with ADAL redirect authentication in MS Team Desktop client recently.
We have a custom Teams app package (Team Tab) to display a page on our application server. The page uses ADAL JS library to get Graph token to access One Drive. Since the page is displayed in iframe and will be used in Teams desktop client, we use page redirect authentication in ADAL. From debug console, we can see the issue happened when ADAL sent request to “login.microsoftonline.com”(login_hint parameter is used to specify current user account). The flow stopped with error saying the “login.microsoftonline.com” can’t be displayed in iframe. In the past, “login.microsoftonline.com” simply redirected the browser to the specified redirect URL and auth flow completed without any problem.
Our application server has implemented SSO with Azure. Implicit auth flow is used to get the token. The issue only happens in Teams desktop client, we use ADAL popup (not supported in desktop client) to get token in browser. The flow was working before April. Seems to me that something has changed recently at the Microsoft login page.
Just wondering if anybody has the same issue. Any suggestions will be appreciated.
Have you looked at using Teams SSO, which uses MSAL, instead of ADAL? See here for a sample: https://github.com/pnp/teams-dev-samples/tree/master/samples/tab-sso
I'm implementing login functionality on my site and I'm running into some problems when sending jwt tokens as cookies.
When the user logs in on the frontend, a POST request is sent with "credentials: 'include'" (I'm using fetch) to my backend API, which returns a jwt token if the login was successful. This all works fine, and I can see the cookie in chrome dev tools, and performing actions that require authentication work fine.
However, when I refresh the site, the jwt cookies disappear. I have ruled out errors with expiration. Through experimentation I've figured out that the domain is the problem. The cookie's domain is "127.0.0.1" from the locally hosted instance of the API, which is different than the domain of the locally hosted website. If I manually change the domain of the cookie to the same as the website, the cookie doesn't disappear.
But that does not solve my problem permanently, as the backend API is hosted on a different domain than the frontend. I've been reading up on cross-domain requests but I'm not sure how to proceed from here. I control both the frontend and the backend, but I'm starting to wonder if I might be going about this the wrong way? Would the simplest solution be to host my api on, say 'api.mydomain.com' instead?
I'm currently try to develop an Office web addin, integrated in the Outlook (Read and Compose).
Everything works fine, except the authentication process.
Indeed, We have to authenticate the user from within Azure AD to access another application (our own application using the Azure AD Architecture where we need to call some web apis)
The solution I used is issued from this great article from Richard diZerega :
Connecting to SharePoint from Azure web app
This solution (we opt for the last scenario) works fine in our Desktop and Web based solution.
But it clearely doesn't work in phone web app , IOS app.
The problem comes from the popup Windows allowing the user to log in.
Actually, window.open, window.location.replace etc ... don't work "as expected" in our Outlook frame.
Everytime it open a popup window. (This is a good solution when the user use the desktop or web Outlook application)
I remember read somewhere that the Office Window where the plugin is loaded, is a secured Window where we can't do any sort of redirection.
I tried to work with ADAL.js, enabling the implicit flow of course, but the problem is the same. We need to redirect the frame to the Azure AD login page.
Finally, the question is : How to deal with an OAuth2/OpenID authentication in an Outlook web addin, and when we want it to work with all kind of devices ?
Login in Adal.Js is a page redirect by default. You don't have pop up issue. Adal.Js gets idtoken initially to be used for your own back end. It also does iframe requests to get access tokens for API endpoints. Office365 APIs support CORS api requests and you can use adal.js to send requests. Tokens will be attached to the requests if you define the endpoints in the config.
You can read about examples here: https://blogs.office.com/2015/03/06/increasing-opportunities-javascript-developers-office-365-platform/
or here : http://www.andrewconnell.com/blog/adal-js-cors-with-o365-apis-files-sharepoint
Having just implemented this, I have a pretty basic question about how authentication and oauth work together. I have a sample web app client (ckclient) that accesses a REST API (commitapi) for managing their commitments. This follows the model of having an app like LinkedIn displaying a user's Tweets (via Twitter) as described in: http://www.slideshare.net/coldfumonkeh/oauth-demystified-hopefully
In my simple app, a user goes to the web app client and asks to see their commitments. I am using Restlet and the user is redirected to a page where they can choose their OpenId provider and login. They are they redirected to a page where they can approve access to their commitment resources. Everything works fine.
But, the web app client doesn't know who the user is! All the authentication is done with the REST API, not with the web app client.
So my first question is... is this a bug or a feature?
My guess at the answer is that this is a "feature" - that is the way Oauth works - you don't WANT the web app client to know the userid/email address stored with the resource server (commitkeeper in my case, Twitter in the slideshare above).
If that is correct, then if I want the web app client to know who the user is, the web app client should provide user authentication. Since I am using Google's UserService on the server side, I also implemented UserService based authentication on the web app client. And now, if the user also does the web app client authentication, then the web app client has the identity of the user. So that is all good.
Combining these two also works - but I can't quite understand why.
On the web app, I login through Google's userService (technically with a GaeAuthenticator, that only uses Google accounts). Now the web app knows who I am and can display my email address.
From the web app, I ask the server for my commitments. The server responds by giving me the login page where I can pick my OpenId provider.
2a. If I pick Google, the UserService seems to know that I have already logged in through the web app and shows me my commitments.
2b. If I pick Yahoo (or something else), I have to authenticate with Yahoo and then I am shown the commitments for that Yahoo user.
This all seems fine to me - except for how does the UserService know that I already logged in? The webclient is at x.appspot.com and the server is at y.appspot.com. Is the answer as simple as the UserService is integrated across all of appspot.com?
In any case, thanks to anyone who can answer these two questions - or just confirm that I am on the right path.
(Note: I am using Google's UserService to create the login urls, my web app client and resource server are on appspot, using Federated Authentication, and all this is Java).
Well, the answer to the first part of the question is "feature" - getting resources from a ResourceServer via OAuth is not supposed to expose any user related information to the web app client.
I will pose a more specific question regarding how the UserService does its magic.
I'm plan on deploy a Java application to Google AppEngine and use federated login (still experimental according to Google). The application is pretty simple Java EE application which expose RESTful interface for simple CRUD operations.
I then want to be able to authenticate to this application using Windows Client Application written in C#.
I think the application should be able to open a window with a browser in ti which will present the login page of my web application and after successful authentication I should be able to get the login token or a cookie to use in the rest of my HTTP requests.
Is it possible to do such thing using federated login? I've found a post explain how to do it using google proprietary login.
Thank you,
Ido.
I've manage to make this work much easier then I thought it would be.
When I send HTTP request to my web service I get 302 Found response with response header name Location which point to the login page.
I use WebBrowser control, register to it Navigated even and navigate to the URL in the Location header.
When the Navigated even fire I use the code from this answer to get the cookies container.
I check each cookie until I find one with the name ACSID and store it.
For every web request to my service I add cookie name ACSID with the value saved at step 4.
This is not the most secure way of doing this. I will add check for the domain of the cookie but this looks good.