We're using AppAuth for a macOS application to authenticate Google accounts. This has been working for years, except recently Chrome has started to block all http connections by default. The loopback server in AppAuth is hard-coded to work with http connections only. The following issue also seems to have gone unanswered: https://github.com/openid/AppAuth-iOS/issues/624
What other options do we have for using a https loopback server on macOS for OAuth2 authentication? We need the loopback server to be able to extract parameters Google sends back after authentication. Asking users to switch from Chrome is not desirable.
Interesting - with loopback desktop logins there are two URLs involved:
The URL in the desktop app, which is meant to be HTTP according to OAuth standards, since it runs on end user PCs. Using HTTPS would require the entire user base to host SSL certificates, which is highly impractical. Typically a loopback URL is a value such as http://localhost:8000, where the port number is often calculated at runtime.
The URL used to invoke the system browser is a value such as https://myauthserver/authorize?client_id=xxx&redirect_uri=http://localhost:8000..., and this should be HTTPS of course.
PROBLEM DIAGNOSIS
I'd be very surprised if Google have blocked this if you are using standard desktop logins, since it has been referenced on their Native Apps Page for years.
Are you sure something else is not the cause? One possibility might be lack of a user gesture in the system browser. Is the problem consistent and are there any differences in these cases:
Make Safari Browser the default before login
Make Chrome Browser the default before login
Make Chrome Browser the default before login and clear browser cache
Let me know and I may be able to suggest some next steps ...
I am running two Windows server 2016s with IIS 10.0.14393. One server for staging purposes, and one for production.
The application has one "front-end app" and one "back-end REST api" running on the same IIS server. The front end communicates with the backend (suprise!). The difficulty I am facing is that the staging server works as expected, i.e no "Sign in" box appears when entering the front-end web page (React). However, on the production server this box pops-up.
When the page is loaded, there is javascript that fetches some information from the API, and it seems that this async fetch is causing the pop-up to occur (the request is in pending mode until login).
I have studied the configuration of IIS on the two servers but can't seem to find any obvious differences.
Both instances have both windows authentication and anonymous authentication turned on for both front-end and backe-end. I need this as the API has different types of authentication for the endpoints.
Anyone that has solved a similar issue?
Thanks
If someone experiences a similar issue the following link may help: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
In my case I was sending the request to the api with the full domain url. The problem was fixed by just using the machine name (and port in my case) when sending the request. If the whole domain with punctuation is used, the system believes that the request is meant for the Internet and not the intranet, and will not include any credentials.
Another, and probably more robust solution, is to add the site in question to: Internet properties -> security -> Local intranet -> sites -> advanced.
In a company network there is a web page, which uses kerberos single sign on. I am connecting to this network via VPN.
When using Mac, I can just write in the console kinit username#REALM.LOCAL, I get the ticket and after this I can open the web page in a browser and it works.
The other story happens on windows. I have my PC, I don't want it to become a member of the company domain. Via MIT Kerberos Client I can get a kerberos ticket, but of course no browser is aware of its existence.
Is there a way to feed this ticket to a browser on windows?
Safari is very friendly, it will give your kerberos tickets to anybody. IE and firefox need to be configured to do this and I'm not sure if they will have access to the kerberos tickets unless your windows box is in the AD domain.
Basically, you need to configure your browser to support SPNEGO. With firefox, you need to tweak some variables in about:config See
http://www.microhowto.info/howto/configure_firefox_to_authenticate_using_spnego_and_kerberos.html
for the exact details. IE is a whole lot trickier.
I have a web application with Windows Authentication enabled. It is working only with localhost though I have set Bindings. Ping to IP and hostname returns result.
Any help would be appreciated
Have set authentication to windows and impersonate to true. NTLM has been moved up.
Also tried adding the site to Intranet and Trusted Site list. Windows authentication is enabled in IE as well.
Both the server and client is on the same domain ... in fact it is not at all working in server itself.
Any help would be appreciated.
With the detail you've given it is a bit hard to give concrete advice so I'll give you a method I've used over the years to try and track down where the issues is.
With the current setup put an image on your webserver and try to retrieve it in the browser using the exact address. Do this on the server itself first and if that works then do it on a client machine.
If it works on server but not on client then there could be a client browser issue/a network issue/a dns issue.
If it doesn't work on the server then change the file level and IIS permissions to anonymous for just that image and the folder / website it is in. Then test the URL on the server in a browser and on a client in a browser.
If it works you've got a permissions issue with NTLM.
Hope this helps you narrow things down.
Dorje
I heard that on Windows you can login from a web browser to the web server without going through the usual login entering username and password but using instead the credentials from Windows directly, using the NTLM protocol.
How is this achieved? Does the web server need to support some additional authentication?
Update: I'm asking for a generic web server, not just IIS. How to do that on Apache for instance?
The webserver just needs to be configured to support Windows authentication (which will be NTLM, or - better - Kerberos if both client and server are W2K or later). I believe that IIS or Apache can be configured to do that.
The browser also has to support this - at least IE does so (not sure about the others, it may be possible). edit: looks like firefox has some support for this too, and safari on MacOS
edit: for details on apache, google modules for NTLM authentication. Kerberos modules also exist. as per other answers, this really only works on an Intranet - not just because the browser needs to be in an Intranet zone (only applies to IE), but because any intervening firewall will typically stop this working, and because the necessary interdomain trusts will probably not exist. It's also a bit trickier to make work if the apache server is on UNIX, and especially if you also have Kerberos servers on UNIX in the mix, but still possible.
It will only be seamless in a specific situation; namely the webserver needs to support NTLM (for example, IIS), and it needs to be in a zone that the client is configured to trust (The "Intranet Zone" in IE parlance, unless the end user has tweaked their settings)
If your webserver and client pc's are on a network secured by Active Directory or similar, you can set 'Windows Integrated Security' in IIS on the web server for the website which automatically logs in all I.E clients (That are allowed).
As stated previously, NTLM is typically used if your back end is Windows Managed (MS Active Directory). However, there are also modules available for Apache that will tie into this: mod_ntlm.
Since this is it's own protocol, it is required that the browser is able to understand this protocol and reply to the authentication challenges. I don't know which browsers support this off hand, but my assumption would be that most do.
From my experience, kerberos is more of a prefered method, but I have not worked with it much, so unfortunately, I don't have much advise as far as that goes.
On a side note, I recall reading somewhere that the JRE also has ways of tying into NTLM on your web server in order to obtain identity information for the authenticated user. As stated previously, .NET has support for this as well.
Also, Firefox does not support NTLM by default but it can be configured using the following tut: http://www.crossedconnections.org/w/?p=89
If you set the IIS settings to require authentication then your users will need to log in to access the page. They then have any rights (if not an interface) to anything on that server that they would if they logged in the normal way (from the console).
Other than this, I am not sure what you are referring to.
Yes this is possible. It is often used in intranet applications where users are. windows uses NTLM or Kerberos to authorize the user against a central service, typically Active Directory on the windows platform. On the .NET platform the current user information can be accessed through the System.Threading.Thread.CurrentPrincipal.Identity instance.
You might also want to look into Jespa. It seems a little bit more straight forward than Kerberos but provides good ntlm sso capabilities.
I was looking for more information about Kerberos (because NTLM, even v2, become deprecated with AD 2008), and I found this article, explaining how make it work with Apache (as you mentionned it).
http://blog.scottlowe.org/2006/08/10/kerberos-based-sso-with-apache/
This question is probably outdated (or at least solved), but if it can help someone ...