Support passing tokens with HTTP Basic Auth for API and WebSocket #4330
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We first check for the access token in the `Authorization: Bearer
{token}` header, if we can't find it there we fall back and check if it
has been supplied as the HTTP basic auth password. We ignore the
username, but it needs to be set in some environments, especially when
the username and password is part of the url
(ie. `https://:password@host.com` doesn't seem to work in Firefox, or
curl).
The audience check was a protection to ensure that we don't use a token destined for someone else, but we only ever generate these JWT tokens for ourselves. So there is no need for checking the audience anymore. This should not compromise security, because as long as the server-side client secret is not compromised, there is no way to tamper with the JWT token. This will allow us to use the legacy JWT tokens for authenticating websocket connections when the web service and the websocket service run on different hosts (in localhost we have: `http://localhost:5000` for the web service, and `http://localhost:5001` for the websocket service).
Current coverage is 93.84% (diff: 100%)@@ master #4330 diff @@
==========================================
Files 311 311
Lines 17110 17142 +32
Methods 0 0
Messages 0 0
Branches 1019 1021 +2
==========================================
+ Hits 16055 16087 +32
Misses 950 950
Partials 105 105
|
|
Marking WIP as browsers apparently don't support this, we should have investigated more yesterday before jumping on this solution. Anyway, @robertknight is doing some research first. |
|
After some additional testing of different browsers using a tiny Go server, it looks like basic auth isn't going to work for us.
|
|
Closing, the solution to the browser issues with basic auth is in #4334. |
This was referenced Jan 27, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@robertknight mentioned that the WebSocket JavaScript API does not support passing any custom headers to the request. The way we initially thought we would authenticate websocket connections is the same way as we do API requests, with a
Authorization: Bearer {token}header.What does work with the WebSocket JavaScript API is passing the HTTP basic auth username and password in the URL (
wss://username:password@hypothes.is/ws), which lead us to implement another way of authenticating requests by passing the token as the HTTP basic auth password.Note: Some implementations (Firefox, curl) do not support an empty username, in this case the client should just send a dummy string in the username (e.g.
wss://X:{token}@hypothes.is/ws).