Hey everyone, I need some help with a concept that I am struggling to configure.
I have set up a vaadin app from Create a new Vaadin app: configure views and theme with security out of the box and PostgreSQL.
So everything is fine with login, however, I want to do the following:
Have a button that can create an API token for this user. How can I create an API token that is “derived” from the logged-in user? Some sort of a generation with a combination of user session details?
Expose an SSE endpoint (or a simple GET endpoint for a test) that can be accessed only by valid tokens. Depending on these tokens I will store the payload and match it to the user the token belongs to.
So I probably need to generate some sort of a jwt with each button press from the logged in user? With encrypted data inside, having the encryption key on the server? Also, how does a person create and manage these tokens in such cases, do you have examples/theory? Vaadin login out of the box is using sessions, right? Can I/Should I change to JWTs and will that help?
The straightforward approach would imho be to just generate a random token for each user and store it in the database alongside the rest of the data about that user. Your SSE endpoint can then do a trivial database lookup to find the user for that token.
The other alternative is indeed to generate a JWT which means that your server has a secret key (or a public-private key pair) to sign a token and verify that a received token is properly signed. The main reason for using this more complex approach is if it allows you to optimize performance by not doing a database lookup but instead just use data from the token to make decisions. This is especially important with microservices where the same token can be passed from service to service which would otherwise require a database query for access control in each service. Another reason is if there are independent servers that don’t have access to a shared database. If you have neither of those requirements, then a random value is probably preferable over JWT.
So assuming I have unique user names, I could generate multiple JWTs for a user and signing them with a service secret.
So you are saying that for the endpoint I don’t need Spring Security even, right? The endpoint could be “open bar” and expect a JWT in the header. When receiving a request I can just attempt to verify the signature and proceed on success?
It’s your choice whether to use Spring Security or not. The benefit of using Spring Security is that there’s a smaller risk of accidentally omitting some small detail that might have a big impact for security. The drawback is that you have to figure out how to configure Spring Security to use different access control methods for different URLs.
In either case, it might be good to first create a separate prototype project with only token authentication to help you figure out the basics and then you can separately investigate how to integrate that into your existing project based on what you have learned from the prototype.
Could also point out that the requirement for having multiple tokens per user doesn’t invalidate the potentially simpler approach of generating random tokens. You would just have to define an 1:n relationship between users and generated tokens.
Thank you so much for the insights, I think I will generate JWTs to skip database calls and won’t use Spring Security since I need this whole implementation for just one endpoint. I think I can manage it properly!