Auth: support JWT token based authentication

[simlawr]

Kirby has support for session/basic authentication but this does not work so well in distributed systems. Supporting JWT token based authentication would allow for stateless sessions.

[lukasbestle]

This has been discussed several times during development of Kirby 3 and also since its release. We last discussed this last week in Slack. Here's an excerpt from our answers:

@bastianallgeier The biggest security problem that we have with Kirby is that it is self-hosted and we cannot automatically assume best practices in terms of stored credentials / ssl certificates, etc. That was the main issue why we sticked with session based authentication as the main way to authenticate and basic auth as the second best solution.

@lukasbestle I've thought a lot about JWT when developing the auth scheme for v3. Like Bastian wrote, we cannot assume secure storage of credentials on the server. That's why we cannot use auth schemes that rely on asymmetric crypto with a private key on the server. JWT needs that to sign the tokens. So JWT are unfortunately not going to work for Kirby. 😞

[simlawr]

I appreciate the concerns with credential storage but secure storage of session files cannot be guaranteed either, or for that matter any other secret (database credentials, API keys etc).

I'm not sure to what extent you can or should try protect against this. 🤔

Keeping sessions as the default (I was not suggesting changing this) and providing JWT as an advanced option, with obligatory health warnings, would be really nice.

Alternatively, make authentication pluggable as suggested by https://github.com/getkirby/ideas/issues/254.

[lukasbestle]

secure storage of session files cannot be guaranteed either, or for that matter any other secret (database credentials, API keys etc).

It can! Our session implementation uses a session key that is contained in the session ID. The session can only be accessed if that key is provided by the client (which is ensured using an HMAC in the session file on the server). So even if you had read access to the session files on the server, you wouldn't be able to take over a session without the key that is only present on the client.

Of course that won't protect against write access to the server by an attacker, but in that case you are screwed anyway. Accidental read access is much more common though (web server with directory listings enabled etc.).

Keeping sessions as the default (I was not suggesting changing this) and providing JWT as an advanced option, with obligatory health warnings, would be really nice.

Alternatively, make authentication pluggable as suggested by #254.

I agree with that, especially with the idea to provide a plugin API for this. There could then be a JWT plugin or other types of auth plugins.

However this feature has so far not been requested by many users and we need to prioritize to make everyone happy. It's definitely something we are open for, but it may take some time.

[simlawr]

It can! Our session implementation uses a session key that is contained in the session ID. The session can only be accessed if that key is provided by the client (which is ensured using an HMAC in the session file on the server).

The Kirby documentation on sessions doesn't state the session file is encrypted:

Each session has a session ID that generally gets stored in a cookie in the visitor's browser. The actual data of the session is stored in a session file on the server that matches the session ID.

Perhaps, it should say "...stored in an encrypted session file..." to be clear.

However this feature has so far not been requested by many users and we need to prioritize to make everyone happy. It's definitely something we are open for, but it may take some time.

It's a niche feature but hopefully someday. Thanks for considering.

[lukasbestle]

Session files are not encrypted, they are signed with the key. But as that's an implementation detail, we haven't added that to the documentation.