HTTP Basic Authentication in URL supported or deprecated

Question

On a project we spent considerable effort to work around basic authentication (because webdriver tests were depending on it, and webdriver has no api for basic authentication), and I remember basic authentication in the URL clearly not working. I.e. could not load http://username:password@url

Just google "basic authentication in url" and you will find tons of people complaining: https://medium.com/@lmakarov/say-goodbye-to-urls-with-embedded-credentials-b051f6c7b6a3

https://www.ietf.org/rfc/rfc3986.txt

Use of the format "user:password" in the userinfo field is deprecated.

Now today I told this quagmire to a friend and he said they are using http://username:password@url style basic authentication in webdriver tests without any problem. I went in my current Chrome v71 to a demo page and to my surprise I found it indeed very well working: https://guest:[email protected]/HTTP/Basic/

How is this possible?? Are we living in parallel dimensions at the same time? Which one is true: is basic authentication using credentials in the URL supported or deprecated? (Or was this maybe added back to Chrome due to complaints of which I can't find any reference?)

Answer 1

Essentially, deprecated does not mean unsupported.

Which one is true: is basic authentication using credentials in the URL supported or deprecated?

The answer is yes, both are true. It is deprecated, but for the most part (anecdotally) still supported.

---

From the medium article:

While you would not usually have those hardcoded in a page, when you open a URL likehttps://user:pass@host and that page makes subsequent requests to resources linked via relative paths, that’s when those resources will also get the user:pass@ part applied to them and banned by Chrome right there.

This means urls like <img src=./images/foo.png> but not urls like <a href=/foobar>zz</a>.

The rfc spec states:

Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used.

Applications that render a URI for the sake of user feedback, such as in graphical hypertext browsing, should render userinfo in a way that is distinguished from the rest of a URI, when feasible. Such rendering will assist the user in cases where the userinfo has been misleadingly crafted to look like a trusted domain name (Section 7.6).

So the use of user:pass@url is discouraged and backed up by specific recommendations and reasons for disabling the use. It also states that apps may opt to reject the userinfo field, but it does not say that apps must reject this.