[thayne]

That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed.

And sometimes it isn't practical to require a POST request or a cookie.

And the risk of a url leaking can be greatly mitigated if the url is only valid for a short period of time.

[ta1243]

> That isn't an inherent problem with having a secret in the url. The problem is the url was leaked somewhere where it could get indexed.

Technically you're right -- after all sending an authentication as a separate header doesn't make any difference.

    GET /endpoint/?Auth=token

or

    GET /endpoint
    Auth: token

Sends the same data over the wire.

However software treats URLs differently to headers. They sit in browser histories, server logs, get parsed by MITM firewalls, mined by browser extensions, etc

using https://user:[e-mail]/endpoint or https://auth:[e-mail]/endpoint

Would be better than

https://site.com/endpoint/user/pass or https://site.com/endpoint/?auth=token

As the former is less likely to be stored, either on the client or on the server. I don't do front end (or backend authentication -- I just rely on x509 client certs or oidc and the web server passes the validated username)

[paulgb]

For better or worse, basic auth in the URL isn't really an option any more, (e.g. see https://stackoverflow.com/a/57193064). I think the issue was that it reveals the secret to anyone who can see the URL bar, but the alternative we got still has that problem and also has the problem that the secret is no longer separable from the resource identifier.

[thayne]

The browser could hide the secret after it is entered.

[paulgb]

Yeah, and it would still be useful for queries that never appear in the URL bar (like EventSource and WebSocket, where setting an Authorization header is not something that’s exposed by the browser)