[SaltNHash]

You understand it perfectly. This is an example of an SPA that displays content based on authentication/roles – all client side. This was to demonstrate the simplest, most straightforward implementation in a few minutes. If you look closer, the authentication is secure by a signed-JWT which can easily be extended to server side content customization and direct api/db access. Developers in our beta program are already doing this across ReactJS / NextJS / Java / Dotnet / PHP/ Etc.

[e12e]

Right. I hope the example can be extended to include a sample api service - as understanding how to verify the jwt, check blacklisted tokens are essential to actually using this.

I'm worried junior devs might look at such examples and believe it is real code.

[SaltNHash]

That point is pure gold! This is such a critical aspect that we hardly see addressed even in the leading platforms. This exact sentiment was the drive behind our SDKs primary premise: Assume a breach! Assume an error-prone junior dev. Assume belief an example code is real code. We aim to have our technology protect user's authority/identity from buggy developers. We want to protect the organization's systems from mistakes the developers or administrators have made. We aim to protect companies from themselves. Our documentation is in its very early days. We've got the technology, but we don't have a (much needed) sample api service yet to demonstrate how the dev DOESN'T need to verify the JWT or qualify against blacklists (the SDK will do it), DOESN'T need to worry about session hijacking, etc. But that's exactly what we're working towards.