There are two parts to this: Authentication and Authorization.

The first is making sure someone else is who they claim to be. The second is about if someone is allowed to do a certain action.

Authentication is most important if you look at different parties. E.g. your client might need to authenticate for your server to trust it’s inputs. Now the question is does your nuxt app actually require authentication or do you only need to authenticate against a backend server? The nuxt app by itself hardly can do proper authentication, as the whole source is readable on the client so there’s not really a secret to authenticate a user by.

For authorization you could just send the nuxt app a list of permissions once authentication (probably by the server) is done and handle/modify however your app needs to handle it (timeouts or things like that).

This is basically what the person did with their JWT token. Put the part required for authentication in the httpOnly cookie and put the part for permissions in a js readable cookie, which now has nothing to do with authentication anymore, but is only meant for authorization.

The cookie will contain whatever you need for your server to maintain a session. In phoenix you can put the user_id on the cookie, because it’s signed and you can be sure it’s not changed if the signing secret is not compromised. But other systems just send e.g. a session ID and store actual data on the server or whatever. The key is that those cookies are to be kept httpOnly. It could also be a JWT stored in the cookie, but it doesn’t need to and imho there’s not much reason for it to be a JWT. For httpOnly cookies there’s no real benefit from a JWT over just Phoenix.Token.

For handing of data (permissions are also just data) to your nuxt app you need to use a transfer method, which is readable by js. Could be a normal cookie, could be an api request or anything the js in the end has access to.

Now you seem to be very cautious about security. With e.g. JWT and public key crypto (not shared secret) you could encode the permissions so the nuxt app can validate that the permissions came from your server, even though the private key is not on the client, only the public key would be. So you can be sure permissions are not altered since the server sent them.

What you cannot do however - without the server - is check if the permissions are current for the user, which is why usually JWTs are set to only be valid for small amounts of times. Your server has no way to actively revoke the permissions the JWT gives within your nuxt app once both are no longer connected.

Now it’s your turn to decide how rigidly you want to enforce authentication/authorization in your nuxt app. If the server is available you can always reauthenticate/ask for permissions of a user, but if that’s not the case you can just work with what you got from the server at earlier times. As mentioned prev. authentication just on the client without a server is not really secure. You need to make the decision what you allow the user to do in case the server is not available and maybe check authentication/authorization again when trying to send data to the server, once it’s available again.

Why not create an endpoint which returns information about the current user (it could be a “me” graphql query) that returns the current user plus roles if they have a valid cookie, or null if there is no user. You can call this endpoint at the top level of your app and pass the user and roles down to the lower level components on the frontend where needed.

Unless you have a very specific need to use JWTs then I think this is a much easier approach to use.