Can you pass user/pass for HTTP Basic Authentication in URL parameters?
Solution 1
It is indeed not possible to pass the username and password via query parameters in standard HTTP auth. Instead, you use a special URL format, like this: http://username:[email protected]/
-- this sends the credentials in the standard HTTP "Authorization" header.
It's possible that whoever you were speaking to was thinking of a custom module or code that looked at the query parameters and verified the credentials. This isn't standard HTTP auth, though, it's an application-specific thing.
Solution 2
http://username:[email protected] will works for FireFox, Chrome, Safari BUT not for IE.
Solution 3
Passing Basic authentication parameters in URL not recommended
There is an Authorization header field for this purpose check it here: http header list
How to use it is written here: Basic access authentication
There you can also read that although it is still supported by some browsers the suggested solution of adding the Basic authorization credentials in the url is not recommended.
Read also chapter 4.1 in RFC 2617 - HTTP Authentication for more details on why NOT to use Basic Authentication.
Passing authentication parameters in query string
When using OAuth or other authentication services you can often also send your access token in a query string instead of in an authorization header, so something like:
GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD
Related videos on Youtube
Craig Vermeer
Updated on September 18, 2022Comments
-
Craig Vermeer almost 2 years
I believe this is not possible, but someone I know insisted that it works. I don't even know what parameters to try, and I haven't found this documented anywhere.
I tried http://myserver.com/~user=username&password=mypassword but it doesn't work.
Can you confirm that it's not in fact possible to pass the user/pass via HTTP parameters (GET or POST)?
-
Admin over 12 years@sam - what? How would the complete URL look like?
-
Admin over 12 yearsAll in the spec ietf.org/rfc/rfc1738.txt (3.1)
-
Admin over 12 years@sam - Sorry, I just failed to parse your comment for some reason.
-
-
Craig Vermeer over 12 yearsThanks, this is just what I was looking for ... it's not critical that it's GET parameters, just that I can craft it into the URL.
-
Moshe Katz over 10 yearsThis capability was removed from Chrome 19+. See code.google.com/p/chromium/issues/detail?id=123150
-
Hendrik over 10 yearsNice. Make sure to also encode your password in case it has special characters. Just open your browser's console
encode("my&password&")
. Returns you the encoded string to use after theusername
-
womble over 10 yearsBy my reading of that bug report, it got added back into Chrome 20. Certainly, I'd expect to see a lot of continued complaining about it if it hadn't been.
-
womble over 10 yearsAnd how does one go about encoding an Authorization header into a URL?
-
womble over 10 yearsIsn't that the form you stated was now deprecated?
-
womble over 10 yearsThe question you answered with "There is an Authorization header field for this purpose" was asking how to put authentication parameters into the URL. If you can't encode HTTP header fields into a URL (which you can't), your answer is a non sequitur.
-
SimonSimCity about 10 yearsI now requested it for Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/…. Slightly different use-case, but addresses the same issue ;)
-
T.J. Crowder about 10 yearsFYI, the
http://username:[email protected]
format is no longer supported by either IE or Chrome, wouldn't be surprised if others followed suit if they haven't already. -
Damien Overeem ツ almost 10 yearsActually works fine in Chrome. Only IE is being a spoiled brat.
-
Chris DaMour almost 10 years@DamienOvereem what version of chrome you on? i'm on mac os x 37 and it does not seem to work for me
-
Damien Overeem ツ almost 10 yearsI have since learned that Chrome had it disabled for a time, but re-enabled this feature later. I've also learned that Safari will throw phishing errors when running into these types of links.. Basically the time of url-based http authentication is over..
-
chicks over 9 yearsBasic http auth is a pain, but since it is easy to setup it is unlikely to ever be completely eliminated. Even http 2.0 includes rfc7235 with no mention of deprecation.
-
C.Samper over 9 years@womble but if password contains '@' then it doesn't work. it gives fatal error, can anyone tell me how we can give username & password at once.
-
C.Samper over 9 years@Diago if password contains '@' then it doesn't work. it gives fatal error, can anyone tell me how we can give username & password at once
-
David Moles about 9 years@AshishJain -- I would try escaping the
@
in the password as%40
. (I don't know if that works, though, and it might depend on the server or browser/server combination.) -
Wilt almost 9 years@LieRyan Apparently someone altered the page since it is not written there any more. I tried to do some googling but nothing showed up so I altered the title also to "not recommended". But if you read chapter 4.1 in RFC 2617 - HTTP Authentication then I can imagine why it is not recommended.
-
Lie Ryan almost 9 years@Wilt: I have to apologise, you are indeed correct. Your hint that the spec was "altered" instigated me to investigate further (an RFC is never modified once it's published/numbered). I just found that RFC 2396 has actually been superseded by RFC 3986, which I wasn't able to find earlier. RFC 3986 does mention the deprecation of username:password syntax:
Use of the format "user:password" in the userinfo field is deprecated.
-
user38537 about 8 yearsDoesn't work in linux lynx either.
-
Ankita over 7 years@womble : Is it possible to get credentials in HTTPOST request?
-
Marco Roy over 7 yearsNote that not all clients (browsers,
curl
, etc) will convert those credentials into the standard HTTP "Authorization" header. I'm dealing with an issue where I must retrieve the credentials from the URL rather than the header: stackoverflow.com/questions/41728885 -
Nathan Basanese about 7 years// , Girish, I like the brevity. Would you mind explaining why this works?
-
frandevel about 6 yearsThis does not work any more in most browsers: Subresource requests whose URLs contain embedded credentials (e.g. user:pass@host`) are blocked ... is the message you will get when trying that
-
rraallvv over 5 yearsIs the password transmitted over HTTP as plain text?
-
Rich over 5 years@AshishJain
@
in the password field can be escaped as%40
. The literal@
is the delimiter. -
Rich over 5 years@rraallvv Yes, HTTP is a plaintext protocol. It was designed to be the same as FTP (and gopher, right?)
-
Jérôme over 5 yearsJanuary 2019, this still works in Firefox.
-
Alex over 5 yearsIt may still work but I wouldn't use it for anything other than testing: tools.ietf.org/html/rfc3986 - Use of the format "user:password" in the userinfo field is deprecated.
-
Magnus over 4 yearsAs of 2019-12-02 this works in Chrome for me but not in Safari.
-
sootsnoot over 4 yearsA lot of time has passed, but it now seems that embedding username:password@ works fine in top-level url's (i.e. not for sub-resources) with current versions of Chrome and Firefox, but not Safari (at least on an iPhone). Looking at the original RFC 2671 (dated June 1999) chapter 4.1, the only real criticism is that the username and password are passed in clear text. But these days most connections use https, in which case the credentials are encrypted. And with free SSL certificates easily available through letsencrypt.org, there is no reason not to use https . So the criticism is nil.
-
MrWhite over 4 years"IE, which no longer support basic authentication." - You mean the passing of user credentials in the userinfo part of the URL. IE still supports "[HTTP] basic authentication". And your example URL should be:
http://username:[email protected]/
. -
Nir Alfasi about 4 yearsMay 2020 - it doesn't work in FF, Safari or Chrome on MacOS
-
ynn almost 4 yearsIn July 2020, on Arch Linux, that doesn't work in Chromium but works in Firefox. On Android, that works both in Firefox and Chrome.