kccarter
If a LiveView needs to refresh a JWT, how can you "push" the new tokens back up to the client without a full page refresh?
A lot has been posted and written about auth, JWTs and LiveView but there’s still one part that we’re struggling to understand. If you have to refresh a token while the user is visiting your LiveView page, how do you send the newly refreshed token back to the client?
We’re using Auth0 and JWTs to authenticate users. Auth0 calls back to our Phoenix app, we do the token handshake and are left with an id_token, access_token and refresh_token which we store in connection’s session-cookie.
We follow the practice of “double authentication” in our LiveViews by first authenticating the HTTP request in a Plug, and then again in the mount call.
The act of authenticating involves checking for the presence of the appropriate tokens and checking that they have not expired. Tokens are passed from the connection to the LiveView in mount.
Our LiveView page is like a dashboard / monitoring page, so it’s reasonable to assume the user might leave it open and running for a long time. Periodically, the user might perform an action on that page which is handled like any LiveView action would be with the addition that we, again, validate the user’s token to ensure it hasn’t expired and that the appropriate permissions are present.
But here’s the problem: If a token has expired, then we want to silently refresh it for the user. We’re able to do so because we have the refresh_token. However, after refreshing the token with Auth0, we now have new tokens (and a new refresh_token) but no way to “push” those new tokens back up to the client such that they are saved to cookies for the next HTTP request.
Our understanding is that we need to perform a full page refresh to update the cookie, which kind of defeats the purpose of short-lived tokens that can silently be refreshed.
We’re trying to get away from using a “session_id” in our cookie and then needing a database lookup to fetch the JWTs.
Just curious if there’s something we’ve overlooked in LiveView that would allow us to silently refresh these tokens without having to reload the LiveView page.
First Post!
tangui
Not sure to understand how you use these tokens and what you intend to achieve.
In OIDC:
- the ID token is used to open a session on the RP (your site) from the OP (OpenID Provider - Auth0 in your case). Open a session generally means setting a local cookie on your site. Note that there’s no correlation between the tokens you received and your session lifetime
- the access token is meant to access external third-party API, and the refresh token to get new access tokens
Are you accessing external API ? If not, why do you need these tokens at all? Storing refresh tokens in cookies seems insecure IMO.
I have the feeling that what you want to do is to synchronize the session at Auth0 with your app, that is kind of Auth0-initiated logout. If so, there’s no easy response as there are at least 3 OpenID standards for that - all being unsatisfying in subtle ways
But you might not need it.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









