Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

jjudge's avatar

JWT authentication, authorisation and session, without a user table/model

As usual, I can't find a channel that seems relevant to my question, so hopefully this channel is okay.

Now, I need to build a simple application, without users, but supporting JWT authentication and authorisation. There will be a simple GUI with actions the user can perform, authorised by some IDs in the JWT payload.

SInce the application has no users, it also has no login pages. The JWT will be generated by an external application and the user thrown over to this application with the token to do their stuff. I guess the session will also need to be based on the JWT too - I can't see a need for a second way to handle the user sessions while the JWT is available, with all the details the application needs to give the user access to carry out a few tasks. But maybe there is a way the two work together?

Are there any packages that can handle this at a high enough level to just be configurable? Or do I need to build my own gates/auth classes to do this, based on low-level JWT packages? The tymon/jwt-auth package all seems to focus around users logging in, but then I'm not sure what it actually handles after that, so I'm not sure if it fits this use-case or not.

Edit: Just to clarify what I mean by no users, there are no user details registered on the application. A web user - someone with a browser - will come along with a valid JWT (probably in the URL, or maybe in a POST header) and will be given access to some resources. When they have finished processing the resources, or the JWT has expired, then that web user has nothing more to do and is sent back to the parent site.

0 likes
4 replies
bobbybouwmann's avatar
Level 88

Well first of all you don't need a session at all. You can simply reuse the JWT token on every request, this way you are never "logged in".

You can use this as an example for generating and parsing tokens: https://jwt.io/

You also talked about not having a user in the system. So when retrieving resources you don't know if it's connected to that specific user/jwt token right? So you basically have an API that will return resources for users with a valid token. They can't store anything right?

You can write a middleware to redirect the users to the parent site when the token is invalid or has expired.

1 like
jjudge's avatar

Hi @bobbybouwmann thanks for the tips.

The JWT token will contain an ID for some resources the [human] user will interact with. Those resources will have been pushed into the application via API from another system - the system that sent the user there in the first place, armed with the JWT.

What that user does will not be linked to any user account on the application. It's kind of like they get a temporary access to a locker in a locker room, and can leave stuff in it, take stuff out, and eat any snacks they find in it. Once they close the locker door, or the key self-destructs after 30 minutes, the locker is taken away and the user cannot see or do anything there again. So yes, the user does store state - they change stuff, authorise actions etc.

All the locker knows, is that the person with their browser has a key that is valid and working right now, so they have the authority to do what they like with the contents.

From what you are saying, it seems that tymon/jwt-auth is probably overkill for what I need, and I probably just need the underlying lcobucci/jwt and perhaps some certificate support, and a relatively simple guard that just checks the JWT validity on every page access (and provides details of the resource authorisation). Unraveling the bits of tymon/jwt-auth I don't need may turn out to be more involved. Would that be a fair assessment?

Do you know of any examples that show how a JWT would be used in a non-one page application? I'm guessing the token could just go into a cookie as the easiest way to handle it. The landing page would have the token in the URL, which it would immediately move into a cookie (I guess?)

bobbybouwmann's avatar

I know Luís Cobucci in person and once attended a meetup where he talked about JWT. You can find his slides here: https://www.slideshare.net/lcobucci/jwt-to-authentication-and-beyond

I'm not an expert with JWT, but you can contact Luís. He can help you out ;)

In general you want to have the token in every request to the server right. So either as a header or as part of the url. If you want the token to stay on the browser you either need a cookie or some form of local storage ;)

1 like
jjudge's avatar

What a brilliant set of slides (you can tell Luís personally ;-)

Almost didn't need the presentation, but it helps: https://www.youtube.com/watch?v=p2tItlr_3QI

As well as JWTs for single-signon between two linked applications, I also am discovering I need to use JWTs with OAuth 2.0 on the same application (Open Banking stuff) so the mention of that in the presentation is well timed too.

I see why you avoid cookies for JWT session handling - it allows load balancing across multiple servers for heavy load sites.

Please or to participate in this conversation.