The JWT specification describes only the payload and how it is sent, but leaves authentication protocol open, which allows the flexibility, but quite unfortunately, flexibility can lead to antipatterns and misdesign.
I'm looking for some well thought and tested enterprise patter for JWT authentication, which I could use or adapt, but I've failed to find something complete.
What I was thinking of is:
- when no Authorization header is met, or the JWT token is invalid, or expired, send HTTP 401
- in order to authenticate, use /login REST channel, send username and password as JSON object
- in order to keep token alive, use /keepalive REST channel, call it every N (5) minutes, receive new JWT token and replace the existing one after each call (the token expires after M (15) minutes)
However, what disturbs me, is the necessity of that /keepalive channel. On the other hand, it forces me to prevent the authentication to expire, even if the user is away (the decision, if we would want keepalive is not yet met) and of course, those are extra calls and extra complication to protocol. What would be interesting, is that server automatically prolongs the token. In session-based environment it happens by resetting the timestamp, here, however, the server would have to sent new token, maybe not each time, but once the token is going to expire in R (say, 10) minutes. But placing it in response body would mean to modify the JSON response protocol (therefore, the solution is invasive and not transparent), and putting an extra HTTP header that client could process could not necessarily be a good pattern. I'd think about just placing Authentication Bearer xxxTOKENxxx header in Response if I'd have to choose...
Are there any ready enterprise patterns which answers my open points? Is my protocol draft a reliable idea? I'd prefer to use something ready than design from scratch.