Hacker News Reader

You should not store any token in the frontend. Instead, have a server doing that and use a classic secure cookie session. The session is bound to the token / refresh token and can then do the token management.

Alternatively, don't use access token / refresh token but an ID token. The refresh of the token will be done via the ID token and the user's session (cookie) to the OAuth provider.

View on HN

JWTs are designed to be stored in the client that needs to be granted authorization to resources. Nothing wrong with storing tokens in the frontend.

Agree this stuck out to me - I think a lot of confusion stems from how to handle refresh tokens - the oauth spec I feel is responsible by the confusion of how it calls apps “clients” and how flimsy it is about implementation (should/shall/must). If you are keeping refresh token locally on the user agent, you really urgently need to provide the user session management tools to revoke those things, and you need to be doing more advanced threat/abuse detection of their usage.

Most people should probably follow the pathways laid out by IdentityServer4 and oidc-client, even if not not using .NET Core (you could absolutely deploy it standalone). Lots of sane defaults, even for refresh tokens and revocations and other difficult specs to understand. It’s well maintained and well thought out.

Reply on news.ycombinator.com