We're trying to test an API that requires HTTP Basic Access Authentication credentials (http://en.wikipedia.org/wiki/Basic_access_authentication) in the request.
Ideally, we could just test the API using a web browser by putting all API parameters in the URL querystring, but we haven't yet found a way to encode the HTTP Basic Access Authentication credentials (username and password) in the querystring.
Does anyone know a way to do this?
Thus far, we've tried:
https://username:password#mydomain.com/
...without success.
username:password#url authentication has been disabled in many browsers for security reasons.
For example in IE:
Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs)
As far as I know, there is no way to circumvent this if this is blocked. It's possible that this can be turned of in Firefox using a setting in about:config. Or use some other browser that doesn't block it - I don't know which ones do and which don't.
Alternatively, consider building a quick web form that submits the option to a server-side language (e.g. PHP) that makes the request, or use a command line client like wget to send the requests. The latter might even be easiest
Related
I have two domains
Example :
a.com and b.com
I try to implement SSO Cross-domain authentication for these two websites
I refer to this link reference How youtube gets logged in to gmail account without getting redirected? to implement like Gmail and YouTube
I have doubt about that
How to send tokens from one domain to another domain using iframe
How to pass tokens in a secure way
If I use an intermediate domain how to prevent that domain call for accessing cookies value I want to set the cookies in the second domain
Please help me to implement I searched but the sample code is not available in asp.net
have you tried this method?
Using Reverse Proxy
As #David suggested, use a reverse proxy like Nginx or HAPorxy to serve both the applications from the same domain - protocol://host:port. All three things should be equal.
Using cookies instead of LocalStorage
If you use cookies instead of LocalStorage, then host ports do not participate in determining site policy. So two application running on the same host but the different port will share cookie without any extra work. To protect the cookie, use an HTTP-only cookie, same-site cookie.
Using URL to share - IFrame only
If you are using iFrame, then you can use URL to share the token. When the outer window is loading the iFrame, send this information via hash like http://localhost:8081/somepage#token=1234
Using hash will allow the page to send data to an inner page without being sent over the wire.
Using window.postMessage - IFrame only
Using window.postMessage, you can simply pass the required data to the inner window/iFrame. As long as you control both the endpoints, you can easily do cross-domain message sending.
In the end, it really depends on your security requirements, ease-of-maintenance, etc.
The best of this is using oAuth https://oauth.net/ provides a comprehensive definition of this.
There are many open-source implementations of oAuth consumer and server available.
The concept is that a third URL will authenticate and maintain the primary session and pass tokens via URL on redirect. The consumers can utilize tokens to request the server for details directly.
Overall benifit is that you will get implementations via open-source communities in a language of your choice, and you will be able to utilise third-party logins. There are other standards you can look into as well are SAML , OpenID and LDAP and products like shibbobleth,CAS and Azure AD.
The situation is:
User is on site http://foo.com/ in one browser tab
This site needs to have a link/button that will open https://bar.com/ in a new tab
https://bar.com/ uses basic auth, and foo.com wants to automatically pass those credentials, such that the user is not prompted by the browser.
The obvious answer here is to pass the creds in the URL, e.g. https://user:password#bar.com. Unfortunately, this good old syntax doesn't work in all browsers (doesn't work in the latest IE).
I'm looking for an alternative that would work across all major browsers. e.g. potentially something along these lines:
The foo.com page builds the Authorization header (by base 64 encoding the creds, ...)
Somehow inject those headers into the request that gets sent to https://bar.com/, such that the request gets authorized with no user prompting.
Even if you are able to achieve sending the credentials to the site on the first request, unless the browser knows the contents of the credentials, it will have to prompt the user again for these credentials if the user navigates to another page on that same (bar.com) site that is protected by basic authentication.
If you have control over the bar.com site, then you might consider an alternative authentication scheme that uses a token generated by foo.com, which bar.com then interprets and, if valid, initializes its session to look at a cookie instead of requiring basic authentication for future requests.
Take a look at this question and this one.
As the title says,I want to build a App that run in browser with a Single Html page.but how to implement the Authentication.and my solution is:
the server-side is all the RESTful APIs,which can used by multiple Platform,web ,mobile side ,etc.and every API that need auth will be get a token to parse,if the API does not get a token return 401.
cuz my first practise is in the browser,so I need to request for the token to get login,and when the app needs to request the auth-APIs,I will put the token in the header for requesting...
and my questions is : does it safe enough? any other better solution?
No it's not safe enough if the token is accessible through javascript for the same reason that you should set your cookies to http only and restrict to ssl.
If a hacker can inject javascript into your app, it can steal the token and use it from their machine.
For that reason I suggest you use a secure, http only cookie instead of the token when using a website.
If your API is going to be accessed from a native mobile app then you could add a token to each url.
Having a custom header in the http request might cause issues with certain proxies which might not pass all headers through.
A cookie is nothing more than a standardised http header so you might as well reuse that.
What you could also consider using is OAuth if you're going to allow 3rd party apps access to parts of your API.
There is no reason why you could not use cookies for browser based clients and an ApiKey query parameter for other clients.
I have an API endpoint https://www.example.com/api/authentication which takes username and password as input and returns an authentication token.
In terms of passing username and password, I have two options (at least), namely:
HTTP Basic Authentication (which passes credentials as part of HTTP headers)
HTTP POST parameters
I understand that neither method provides encryption (hence the use of HTTPS/SSL). I also understand why using HTTP GET is is a Bad Idea.
Is there any real difference (aside from the fact that basic authentication feels more idiomatic) between the two methods?
The difference is that basic authentication is a well specified challenge/response scheme that all browsers understand and it is the server that starts it by telling a client that it requires (basic) authentication for a realm. This triggers the browser to show a popup to the user to enter a name/password which it then passes in the headers as you described.
In your second example you have to do all that in your own customized way and create your own login form for the user (etc).
If you deduct this process to the single step of passing the username/password from the client to the server I have to agree that there isn't that much difference but basic authentication implies a bit more than just that.
HTTP Basic authentication implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifiers, or login pages; rather, HTTP Basic authentication uses standard fields in the HTTP header, obviating the need for handshakes.
I want to create an internal website, preferably in asp.net, that uses ajax calls for performing all operations.
The requirements are that the site should use windows domain authentication (to act as a single-sign-on solution) for verifying which user is sending the request. What is the best way to accomplish this in a secure fashion? I am open to a solution using https or cookies or anything else feasible.
( I would prefer regular ajax using jquery since I havent used asp.net ajax but if that solves some issues more easily, then let me know)
The current way I am doing this (not through ajax) is disabling anonymous access in iis and then getting the logged in username from asp.net, but this requires the site to perform postbacks, etc which i want to avoid.
An Ajax request is not different from any other HTTP request when it comes to authentication.
Your user will most likely be authenticated when they access the index of your site. Any subsequent request, Ajax or not, will be authenticated. There is nothing special to do, and your jQuery code will look just like what it normally looks.
Windows authentication is checked on every request.
How this is checked depends which authentication method /provider is enabled and supported on the server (kerberos, ntlm, custom, etc)
Credentials are automatically sent over under certain rules (I believe intranet trusted for IE, I dont recall what else outside of that).
Firefox will prompt you if I recall every time.
Check out:
http://www.winserverkb.com/Uwe/Forum.aspx/iis-security/5707/IIS-6-0-Windows-Authentication-401-Every-Request
The important thing to note is the browser and server will take care of this and prompt the user when necessary.
Also to note is I highly highly suggest ALL traffic is under an SSL connection at this point to prevent sniffing and credential stealing/token stealking (such as is extremely easy for basic auth)
You can enable this protection inside of IIS and use all file permissions or you can control this in your web applications web.config by enabling windows authentication. How this is accomplished though depends on your server config (kerberos support, etc)
You should absolutely:
Use an https connection to transmit username and password
Authenticate on the server side, with asp.net
Leverage the asp.net session to as great an extent as possible.
If you're not familiar with ASP.Net ... well, consider this a good opportunity to learn :)
jQuery is great, but it's just a tool. In this case, it's probably not the best tool for this particular job.
IMHO...