Thank you so much Simon for the run through. I was not aware that we could write Javascript code for these things. Thanks for sharing the code as well.
The system which you have built is partially secure. It would be full proof if you add a hashing algorithm which hashes the initial content (removing the confidential information).
Implementation details
You can use a hashing algorithm to hash the non-confidential data and append it to the final output by the plugin.
With this you can verify that the data which you received has been encrypted by the bubble app (using the same key) and hash helps in checking that the data has not been changes in the transport . This should be a full proof way to tackle this situation. We need to keep in mind that the keys should be change(roll over) after every 90 days.
To those following, I think I found a very elegant solution to handling auth outside Bubble.
I went back to using JWT for the purpose of having tokens with an expiration date - also jwt are well established, so support and documentation is a lot better.
In summary, this is what I do:
On the current user i have a string field called “token”. Privacy is set to allow only current user to view this field.
In a static menu in bubble (in my case the header) I run a custom trigger on page load + every 300 seconds.
The custom trigger runs a backend workflow that does the following:
It checks the expiration data of the current stored token
If the expiration is less then X seconds (600 seconds in the screenshot), create a new token.
The plugin uses a signing secret only read by the backend and takes key value pairs as input (user, scope etc. kan be defined as needed).
The plugin returns a token + a “isTokenUpdated” boolean. If true, save token to the user.
The created token have, in my case, an expiration of 3600 seconds (1 hour), and I check every page load + every 5 min. if its to expire soon. So there is never a risk of an expired token.
The token is then used in the header of api calls either with bubble API Connector or, in my case in a frontend plugin that I use in my app, and I verify the token on the outside app. As the token are created in the backend every n minutes, there is no waiting on when doing api calls.
The jwt-plugin is not published, but if there is interest in it I can polish it up and share it for free.
The Auth0 plugin only does some specific parts of the process, the rest are actually normal bubble workflow actions. In the case, only the first step comes from the plugin. You can check out the plugin docs for more details I think
