3

I am building an oauth login flow and I am not sure if I have done it wrong because I will need to send the bearer token back via redirect URL, like /oauth2/redirect?token=[TOKEN]. But isn't it not recommended to have token passed along through URL? As it is pointed out in this thread:

Don't pass bearer tokens in page URLs: Bearer tokens SHOULD NOT be passed in page URLs (for example, as query string parameters).

Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures.

If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.

I must have missed something in the whole flow and would like to understand more about this matter. Any input is appreciated!

UPDATE

Might not be correct but this is my understanding after some digging. The three means to pass token:

  1. URL (not preferable)
  2. Auth header
  3. Request body

But under the oauth redirect use case, option 2 and 3 not feasible. So option 1 is the only option available. If really needed, token can be encrypted to ensure security.

Cheng Xu
  • 164
  • 9
  • check it here, it may help https://stackoverflow.com/questions/29926041/specify-oauth-token-in-get-url – Haifeng Zhang Oct 14 '20 at 17:55
  • @HaifengZhang that seems to be the exactly same question I had. But is there better way for the oauth use case to avoid passing the token inside URL where auth head or post request are both not an option. – Cheng Xu Oct 14 '20 at 18:00

2 Answers2

2

I think this only means, that you should not use a GET request when the server requires the token, instead you should use POST or whatever is appropriate. In a GET request the parameters are included in the URL and those can end up in logs or other histories, other request types will send the paramters separat from the request URL.

P.S. BTW if you are not implementing the OAuth server yourself, you won't have to send a redirect url containing the token.

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
  • But isn't this to be the case even if it is not used in GET request but in the redirect URL? **If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.** Thanks for the input. For my use case, I am doing both, an OAuth server as well as integration with other 3rd party OAuth so that is why I was having a redirect URL. I will mark this as accepted answer if no input from the others. – Cheng Xu Oct 14 '20 at 17:49
  • @ChengXu - This would only happen in the token-flow, when the server sends back a redirect response, in this case the bearer token is included in the redirect url but is (hopefuly) protected by SSL. If you implement the code-flow though, the redirected url would contain only a code, which later can be exchanged for a bearer token, this exchange would be done with a `POST`request. – martinstoeckli Oct 14 '20 at 20:29
  • @ChengXu - Maybe one misunderstanding is, that the the redirect response is executed by the client, but that's not the case. The redirect url is the response of the server, but the client won't actually do the redirect, so it won't end up in a browser history. – martinstoeckli Oct 14 '20 at 21:06
0

The basic auth header which provides a little extra security as it's required to be through TLS:

In the case of a "Basic" authentication like shown in the figure, the exchange must happen over an HTTPS (TLS) connection to be secure.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

Also, the headers aren't logged in easy places like browser history.

From the spec,

it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body.

https://www.rfc-editor.org/rfc/rfc6750#section-2.3

Community
  • 1
  • 1
akdombrowski
  • 673
  • 4
  • 9