# Implementing JWT authentication with a HiveMQ Cloud broker (Starter Plan) for remote equipment access

**URL:** <https://accelerated-discovery.org/t/implementing-jwt-authentication-with-a-hivemq-cloud-broker-starter-plan-for-remote-equipment-access/256>\
**Category:** Tools\
**Tags:** security\
**Created:** [July 27, 2024, 2:57am UTC](https://accelerated-discovery.org/t/implementing-jwt-authentication-with-a-hivemq-cloud-broker-starter-plan-for-remote-equipment-access/256 "2024-07-27T02:57:52Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![sgbaird](https://yyz1.discourse-cdn.com/flex003/user_avatar/accelerated-discovery.org/sgbaird/32/341_2.png) [@sgbaird](https://accelerated-discovery.org/u/sgbaird)\
**Post date:** [September 4, 2024, 2:46pm UTC](https://accelerated-discovery.org/t/implementing-jwt-authentication-with-a-hivemq-cloud-broker-starter-plan-for-remote-equipment-access/256/3 "2024-09-04T14:46:57Z")

</div>

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.

> <https://stackoverflow.com/questions/74891507/how-to-create-a-permanent-authentication-token-with-auth0>

> **[Persistent access tokens](https://community.auth0.com/t/persistent-access-tokens/107698/5)**
>
> In regards to PAT, this might be useful: Cheers!

There may be a workaround to the expiration, but it seems somewhat involved and might not work well with HiveMQ:

> **[Refresh Tokens](https://auth0.com/docs/secure/tokens/refresh-tokens#for-web-apps)**
>
> Describes how refresh tokens work to allow the application to ask Auth0 to issue a new access token or ID token without having to re-authenticate the user.

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.](https://github.com/mkhorasani/Streamlit-Authenticator)
- [Adding Simple Authentication to Your Streamlit App | by Charan H U | Medium](https://charanhu.medium.com/adding-simple-authentication-to-your-streamlit-app-1779e849b983)
- [GitHub - asehmi/auth-simple-for-streamlit: A simple username/password database authentication solution for Streamlit](https://github.com/asehmi/auth-simple-for-streamlit)
- [Data-Science-Meetup-Oxford/StreamlitComponent at master · asehmi/Data-Science-Meetup-Oxford · GitHub](https://github.com/asehmi/Data-Science-Meetup-Oxford/tree/master/StreamlitComponent)

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.

---

_[View the full topic](https://accelerated-discovery.org/t/implementing-jwt-authentication-with-a-hivemq-cloud-broker-starter-plan-for-remote-equipment-access/256)._