Thanks to @kenzo exploring this in depth, it seems like more effort than it’s worth at the given point, and comes with certain limitations.
In particular, JWTs through Auth0 have a max expiration of 30 days.
There may be a workaround to the expiration, but it seems somewhat involved and might not work well with HiveMQ:
JWTs seem to be geared more towards “sessions” rather than long-term access.
Even getting Auth0 and HiveMQ connected with each other wasn’t very fruitful. Tutorials in this regard are limited or outdated.
@kenzo’s suggested alternative is to use the HiveMQ API (still required to have the paid Starter Plan) to generate random passwords and remove the old ones when the new password is generated. We’ve switched the broker back from “JWT authentication” to “Access credentials” (i.e., username/password combinations).
Later, we can work on adding some kind of “bot attack prevention” (i.e., a login interface or captcha verification). Some potential resources:
- GitHub - mkhorasani/Streamlit-Authenticator: A secure authentication module to manage user access in a Streamlit application.
- Adding Simple Authentication to Your Streamlit App | by Charan H U | Medium
- GitHub - asehmi/auth-simple-for-streamlit: A simple username/password database authentication solution for Streamlit
- Data-Science-Meetup-Oxford/StreamlitComponent at master · asehmi/Data-Science-Meetup-Oxford · GitHub
In particular, the easiest (and least secure, yet still meaningful) approach is to put a single, shared/global password for all users behind some kind of wall.