Doing some first experiments, here's how a #JWT for #swad might look like, containing a custom property that has the "auth info" that's currently stored in the server-side #session ... 🤔

Now add a JOSE header, base64-encode and sign that beast...

I now decided I'll at least aim for some middle grounds: Rework #swad so it only needs a (server-side) #session once a user is #authenticated!

This does have some implications, e.g. passing a redirect argument to the authentication endpoint won't work any more. But experimentation shows a workaround would be to use an "internal redirect" to the login endpoint in #nginx.

We'll see where I end up. Having sessions only for authenticated users should reduce the need for server-side RAM significantly, so I hope 😉

About the #random thingie ... I need random data in #swad to generate unpredictable #session IDs.

I previously had an implementation trying the #Linux-originating #getrandom if available, with a fallback to a stupid internal #xorshift#PRNG, which could be disabled because it's obviously NOT cryptographically secure, and WAS disabled for the generation of session IDs.

Then I learned #arc4random is available on many systems nowadays (#FreeBSD, #NetBSD, even Linux with a recent-enough glibc), so I decided to add a compile check for it and replace the whole mess with nothing but an arc4random call IF it is available.

arc4random originates from #OpenBSD and provides the only sane way to get cryptographically secure random data. It automatically and transparently (re-)seeds from OS entropy sources, but uses an internal CSPRNG most of the time (nowadays typically #ChaCha20, so it's a misnomer, but hey ...). It never fails, it never blocks. It just works. Awesome.