5 ms·

I suggest to avoid flows that expose a token to the client. This example mentions PKCE quickly at the end. You should absolutely NOT use the described flow with

I suggest to avoid flows that expose a token to the client. This example mentions PKCE quickly at the end. You should absolutely NOT use the described flow without PKCE. That said, a much more secure solution is described in the link below. It's also known as "Token Handler" pattern. In a nutshell, keep all the secrets on the backend and also handle the code exchange and tokens on the server, hence the name of the pattern. Then, store the token in a secure cookie. It's way more secure than moving a token into the browser, where a dependency vulnerability could get access to it. https://wundergraph.com/blog/authentication_for_nextjs_with_graphql_and_rest_apis_and_server_side_rendering https://wundergraph.com/blog/authentication_for_nextjs_with_...

mooreds 5y ago
Hmmm. This article explicitly uses an express server to avoid the token being sent to the client. That said, if you must send a token to the browser because you don't want to manage sessions, we've seen folks have success storing the JWT in an HTTPOnly secure cookie. Disclosure: am co-worker of the author.
throwoutway 5y ago
> Then, store the token in a secure cookie. It's way more secure than moving a token into the browser, where a dependency vulnerability could get access to it. Cookies are still in the browser so what difference are you specifically addressing or advocating
- jensneuse 5y ago
  Secure, encrypted, same site, http only cookies cannot be accessed by JavaScript.
  - whateveracct 5y ago
    Sign it as well! For instance: https://github.com/gorilla/securecookie https://github.com/gorilla/securecookie Unless I'm missing something and the payload is effectively signed. Either way, I still like to have signing generically done at this level of abstraction. Then I can put whatever in there. Sometimes the encrypted payload is also signed too - maybe with a per-user secret. Now "log out everywhere" is as simple as scrambling the user's secret, thus invalidating their cookies. Simple.

mooreds 5y ago

Hmmm. This article explicitly uses an express server to avoid the token being sent to the client. That said, if you must send a token to the browser because you don't want to manage sessions, we've seen folks have success storing the JWT in an HTTPOnly secure cookie. Disclosure: am co-worker of the author.

throwoutway 5y ago

> Then, store the token in a secure cookie. It's way more secure than moving a token into the browser, where a dependency vulnerability could get access to it. Cookies are still in the browser so what difference are you specifically addressing or advocating

jensneuse 5y ago
Secure, encrypted, same site, http only cookies cannot be accessed by JavaScript.
- whateveracct 5y ago
  Sign it as well! For instance: https://github.com/gorilla/securecookie https://github.com/gorilla/securecookie Unless I'm missing something and the payload is effectively signed. Either way, I still like to have signing generically done at this level of abstraction. Then I can put whatever in there. Sometimes the encrypted payload is also signed too - maybe with a per-user secret. Now "log out everywhere" is as simple as scrambling the user's secret, thus invalidating their cookies. Simple.