# HiveMQ + Auth0 integration, with possibility for persistent tokens **URL:** \ **Category:** HiveMQ Commercial Offerings\ **Created:** [September 4, 2024, 3:05pm UTC](https://community.hivemq.com/t/hivemq-auth0-integration-with-possibility-for-persistent-tokens/3191 "2024-09-04T15:05:48Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![sgbaird](https://yyz1.discourse-cdn.com/flex035/user_avatar/community.hivemq.com/sgbaird/32/507_2.png) [@sgbaird](https://community.hivemq.com/u/sgbaird)\ **Post date:** [September 4, 2024, 3:05pm UTC](https://community.hivemq.com/t/hivemq-auth0-integration-with-possibility-for-persistent-tokens/3191/1 "2024-09-04T15:05:48Z")
We have equipment that we want to enable temporary, remote access to. We tried switching from access credential authentication on the Starter Plan to JWTs with a JWKS URL pointing to Auth0, and hosting a streamlit web app on Hugging Face Spaces for the interface. We ran into a few issues: 1. JWTs through Auth0 are limited to 30 days, and doing automatic token refreshes seemed complicated. In particular, the equipment needs to stay connected to the broker at all times 2. We couldn’t get the callback URL working properly, pointing back to Hugging Face Spaces (i.e., I don’t think we ever got to the point of generating a JWT that would be accepted by HiveMQ) The overall goal was simple: allow a user to click a “login/verification” button (to prevent bot/spam attacks), and be provided with temporary access to a particular topic on the broker to access the hardware. After going down this rabbit hole, and as a workaround, we are planning to instead use the HiveMQ API to create random credentials and remove the old one when a new one is generated (assuming it’s past the expiration time). > **[Implementing JWT authentication with a HiveMQ Cloud broker (Starter Plan) for...](https://accelerated-discovery.org/t/implementing-jwt-authentication-with-a-hivemq-cloud-broker-starter-plan-for-remote-equipment-access/256)** > > I’m diving a bit deeper into an implementation of temporary credentials for remote access to equipment, carrying on from this comment: I will try the JWT tokens issued by Auth0 and passed to a HiveMQ “Starter Plan” broker. Still figuring out the... > **[Assigning temporary credentials for remote access to equipment](https://accelerated-discovery.org/t/assigning-temporary-credentials-for-remote-access-to-equipment/241)** > > What are some ways someone could go about this? For example, CAPTCHA and email verification, but how to dynamically generate temporary API keys for e.g., MQTT? Thoughts on other solutions, including those for different communication protocols? ... ---
**Author:** ![Daria\_H](https://avatars.discourse-cdn.com/v4/letter/d/dfb087/32.png) [@Daria\_H](https://community.hivemq.com/u/Daria_H)\ **Post date:** [September 13, 2024, 10:52am UTC](https://community.hivemq.com/t/hivemq-auth0-integration-with-possibility-for-persistent-tokens/3191/2 "2024-09-13T10:52:28Z")
Hi @sgbaird, Thank you for sharing the details about your setup and the challenges you’ve faced. 1. It seems the main issue is with the token refresh process from the provider. Could you provide more insight into why your equipment is having difficulty retrieving the new token in time? The Auth0 instructions generally appear straightforward: ![image](https://canada1.discourse-cdn.com/flex035/uploads/hivemq1/original/2X/2/24866ec8deb57f152a45a48c94bb0b31b757027d.png) . 2. Regarding the “callback URL,” it doesn’t seem to relate directly to the HiveMQ Cloud Starter settings. If you could clarify its role or how it fits into your configuration, it might help us address any related issues more effectively. 3. If JWT authentication proves challenging, using simple authentication (username and password) might be a viable alternative for your setup. Please let us know if there’s anything else you need or if you have further questions. We’re here to help! Best regards, Dasha From The HiveMQ Team