ID Token in url is not a security best practice

[csikosbalint]

websocket-api-cognito-auth-sample/frontend/src/views/Echo.vue

Line 63 in d0ca229

this.client = new w3cwebsocket(`${config.WebSocketEndpoint}?idToken=${jwtToken}`);

It is a not a good practice to put sensitive data such as passwords and tokens in the url.
Reason: Although, communication is encrypted and both query strings and headers are going through inside a TLS communication, it is a standard procedure to log $url at the backend (logging headers are not so common). This way ID Token can be visible in logs and could be disclosed. This increases attack surface. Current best practice is to retrieve short term ticket and use the ticket during the ws connection init (as a query string).

[tmokmss]

Hi @csikosbalint thank you for letting us know about it. So there are several ways to achieve WebSocket auth, for example:

1. access token in query parameters
   • Pros: easy to implement
   • Cons: query parameters are often logged directly, hence possible disclosure of tokens.
2. ticket in query parameters
   • Pros: more secure than 1 since a ticket is more short-lived than a JWT above
   • Cons: may need additional resources on backend (e.g. session store, ticket issuer servers, etc) to manage tickets
3. access token in HTTP headers
   • Pros: we don't have cons of 1 and 2
   • Cons: Using headers in JavaScript WebSocket API is not straightforward, requiring some hack like this
4. access token in Cookie
   • Pros: we don't have cons of 1,2,3
   • Cons: you need to set cookie somewhere. Also, sharing cookie cross domain can be cumbersome
      

Although there are some trade-offs between them, I guess 2 or 3 should be preferred when security is your top-priority.

We will update code or docs to align with the current best practice, thanks again.