Assigning temporary credentials for remote access to equipment

Tools
1

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?

EDIT: xref - Temporary credentials - HiveMQ Cloud - HiveMQ Support Forum - users can be dynamically created and deleted via the REST API and JWT authentication also seems to be supported, but this seems to require the HiveMQ Cloud Starter plan to use (est. 249 USD/mo. as of 2024-07-15).

2

LinkedIn comment from Brandon Best:

You could utilize a similar pattern to 0Auth 2.0 which is very common. You could set restrictions on how long the access token is valid for, how much it can be used, and how often it can be refreshed.

3

I would agree to that, using a JWT with limited lifetime, issued, e.g. from keycloak trusted by its pubkey, would be a good solution.

JWT is also highly supported in REST-APIs like FastAPI.
Keycloak also supports Email-validation and reCAPTCHA on registration.
For OPC-UA, a x509 certificate with limited lifetime would be the equivalent: opcua-asyncio/examples/client-with-encryption.py at master · FreeOpcUa/opcua-asyncio · GitHub

1 Like
4

This was very helpful, thanks! At least for a first pass, I will try the JWT tokens issued by Auth0 and passed to a HiveMQ “Starter Plan” broker. Still figuring out the details, such as the web app for requesting a token (perhaps a Streamlit Web App in Hugging Face Spaces [2] or a Flask App in PythonAnywhere), since it seems like I can’t host that natively in Auth0.

See also a somewhat lengthy ChatGPT transcript.

Aside: By switching to JWT for the broker, it disables the typical username/password authentication I’ve been used to with HiveMQ.

cc @kenzo

EDIT: abandoning this approach in favor of something simpler

5

Is spinning up your own keycloak container not an option (see, e.g. keycloak-docker-compose/docker-compose.postgres.yml at main · opensemanticworld/keycloak-docker-compose · GitHub)?. We usually try not depend on third party infrastructure to enable shareability and infrastructure-as-code (=> versioning, reproduceability, etc.)

If you use a public client, a small “serverless” app (means: hostable on Github pages) can be build e.g. with the keycloak js-lib (Securing Applications and Services Guide).
With device-flow enabled, clients could also run on the command line.

1 Like
6

I’ll have a look! A well accepted cloud hosted and “hands-off” option is appealing, but perhaps the one you mentioned is straightforward enough to implement with JWT and a JWKS endpoint.

7

We’re abandoning Auth0 for now. Hosting a keycloak instance on digital ocean or on github pages / readthedocs / etc. might be a good solution in the long-term. Right now, the other person working on this is going to use the HiveMQ API (still requires paid Starter Plan) to generate random access credentials and remove the old one when new credentials are created (and return some kind of error message if it’s too soon to create new credentials).