Hi!
Bought a few sensors to monitor the current temperature of two saunas and the Gateway to access the data outside of the LAN.
App works and gateway is connected. I have found the API to call but:
How do I authenticate?
I know there is documentation about using MQTT but I’d rather use a simple REST API.
Hello,
Here is an example how to poll data from your Gateway:
e.g.
curl -H “Authorization: Bearer 0i0XJhGjpiMdEBRxI+hEXtJoGoL1jM7DFv6c6netsjU=” http://192.168.1.108/history
after setting up the Bearer authentication.
Thanks!
This I can use if I want to talk to the Gateway. I want to use the cloud-API but it have given me a few Ideas to try:
Cheers // Martin
Hello,
If you want to get data from Ruuvi Cloud, you can use our API:
Please note that our API is in beta and while we use it internally and don’t plan to do any big changes, some breaking changes are to be expected especially before we have launched the Ultimate subscription plan.
In short your user flow would be to call https://network.ruuvi.com/register to get verification token emailed to you and then register the verification token with https://network.ruuvi.com/verify .
From /verify you get the actually access token you can use to authenticate to Ruuvi Cloud. Please be careful while developing, we may throttle or ban IPs and accounts which cause exceptional amount of traffic for example by downloading full history data of a tag repeatedly as that resembles a DOS attack to our service.
Thanx!
I found the API alright, just not an automated flow for retrieving the token. Reading mail can of course be done by servers but it quite cumbersome compared to normal OAuth-processes.
What is the lifespan of the token returned from this?
I saw that this is the same flow that You use in your web-frontend.
Of course I will cache the data. In my simple use case I want to display the last few hours temperature in the Sauna to be able to determine if the sauna is on or off.
True, we might add other authentication methods in the future.
Tokens are invalidated after 6 months of inactivity.
Fetching few hours of data for one sensor once per minute or so can be done without caching too, no worries in that case.
So we have now traveled 4 years into the future. My set-and-forget solution has two errors:
Is there still no way for us to do a more system-to-system friendly login than login by mail?
We have not added new login mechanisms.
What would be your preference for system-to-system login? My first instinct would be to accept a key certificate you have created and then allow requests with that certificate to generate new access tokens for specific account, but I’d love to hear thoughts on what would serve your use case
Thanks for the clarification.
For my use case, our preference would be to use a standard OAuth 2.0 Client Credentials flow for system-to-system authentication.
Ideally, we would receive a client_id and either a client_secret or certificate/private key setup, and then use that to request access tokens for a specific account or scope.
Your suggestion of using a client certificate to generate access tokens sounds very reasonable and aligns well with modern machine-to-machine authentication patterns. If possible, we would prefer it to follow a standard OAuth 2.0 approach rather than a custom implementation, since that makes the integration simpler, more maintainable, and easier to support long term.
In summary, our preferred setup would be:
That would work very well for our integration needs.