Oauth2 Access Token

Developers
,
1

Can anyone help me understand how you are meant to use an Oauth2 Access Token in an API/websocket request to access data from a non-public station?

1 Like
2

Hi Peter. The Oauth2 stuff is not a self-service thing, yet (though that is the goal!). For now, there are some things we need to get you set up. We’ll have more info in the next couple weeks!

3 Likes
3

Yes, please. It’s time we started adding this to our applications.

Will this replace the need for an API key?

1 Like
4

It won’t replace the API key - it will augment it. You’ll be able to access some data with just an API key, and more data with the Oauth2 token. Stay tuned for more details soon.

4 Likes
5

Did you all ever do any more with the authorization server and making obtaining the access token available without using swagger and/or the regular WeatherFlow/Tempest site? I have been tinkering with the API in Python lately and I was going to implement a method to obtain an oauth access if there was a way yet. If not, I assume the best way to advertise to anyone using the code is to obtain it via the swagger interface for now? Thanks!

6

Hi Matt. As a matter of fact, we just quietly released a feature on tempestwx.com that allows a station owner to generate a “personal access token” for use in third-party apps. Just sign in at tempestwx.com then go to Settings -> Data Authorizations (or directly: https://tempestwx.com/settings/tokens) and create an access token. Once you have a token, you can use it with REST requests and WS connections:

REST Examples:

  • GET Station Meta Data
    https://swd.weatherflow.com/swd/rest/stations?token=[your_access_token]

  • GET Latest Station Observation
    https://swd.weatherflow.com/swd/rest/observations/station/[your_station_id]?token=[your_access_token]

  • GET Latest Device Observation
    https://swd.weatherflow.com/swd/rest/observations/?device_id=[your_device_id]&token=[your_access_token]

WebSockets Examples:

  • Open a websocket connection
    wss://ws.weatherflow.com/swd/data?token=[your_access_token]

  • Send a JSON message over the websocket connection to start listening for observations from one of your devices. After sending this message your connected websocket client should receive a new observation JSON message every minute.
    { "type":"listen_start", "device_id":your_device_id, "id":"random-id-12345" }

5 Likes
7

Thanks for the info! I had earlier obtained the AT via the swagger interface and was able to use it against the REST and WS interfaces successfully before you just gave me this new interface. Is there any way to revoke those old tokens I obtained via swagger or do they eventually expire after some time? I wondered if they might just expire once I logout but I never tested logging out and seeing if they went away.

This new method of obtaining the tokens is an interesting implementation. I like how you now have the ability to delete the token via the interface. I am surprised you didn’t post the token and/or api key in the request body instead of passing as a query string parameter, but this works and is easy. I’m used to working with oauth spec calls but seldom see anyone actually implement exactly to these specs.

Thanks again for this. It’s a lot easier and I am glad to have the ability to delete the tokens now.

2 Likes
8

We will be adding a “revoke access” option for oauth tokens generated by other apps soon.

2 Likes
9

Following up on this…
@dsj @WFstaff @WFsupport

What is the proper procedure for getting said access token via code… NOT by having a user login and create one, but rather having a user log into a 3rd party app, and have the app request one from WF servers? Is there a REST or WS endpoint?

Need to get this resolved in order to re-release my apps.

–Sam

10

Are you sure this is a proper way to go ? It isn’t hard to get a token via the settings of the station’s page. Also how are you going to check if the one asking the token own’s the station ??? If you open the door everyone could ask access to everyones data … break of privacy in Europe for sure.

11

It will require the user to log in with their WF account… Just like the WF app does. Logging in provides proof itself that user owns the station… I know it’s not 100% proof, but that’s exactly how it is handled in the WF app as well.

And asking the typical, average, everyday user to go to their account, create a token, and paste it into an app is not a good way to go. That will create a support headache.
–Sam

12

I believe WeatherFlow are still working on this implementation. In a nutshell (assuming my understanding is correct), you will need to direct users to an authorization URL where they will enter their username and password. This will provide your application with an authorization code and then the authorization URL will redirect the user to a URL of your choice (this is sent as a query string during in the initial authorization URL). Your server will then need to exchange the authorization code for an access token in the background and you are good to go.

My understanding is for this to work you must maintain a server that allows background scripting and provides the redirect URL.

I am happy for an expert to correct me on any of the above - I am still learning the Oauth2 process.

13

Exactly… so from your information it is all “still in the works”?

14

Yes

I think I am allowed to say that I helped with some initial beta testing, but it turns out that in the case of the PiConsole I will be using the “user generated token copy/paste” method as I do not maintain an active server.

1 Like
15

Your server will then need to exchange the authorization code for an access token in the background

Why can’t that happen in-app? Why can’t all the auth code be in-app?

16

OK, so I am shaky ground here in terms of my understanding, but I believe that the user can only grant authorization by logging into their WF account on the official WF webpage, and that a redirect URL has to be provided. You can’t redirect a user after they have logged into their account straight back to the app. There is no API endpoint for the initial authorization - this has to be done in a web browser.

It might be possible to achieve this in-app on Android/Apple, but I couldn’t think of a way of doing it in pure Python

1 Like
17

I guess that bears the question…

Is it possible… or will it be possible… for a user to get an API key via code? Is there an endpoint for retrieving the user’s API key?

Instead of an OAuth authorization, can an API key be used instead? Would that work the same?

18

tbh I don’t know! I’m certainly not aware of an endpoint that will give you the API key, and my feeling is that the industry standard Oauth flow is the expected route to achieve authorization without the user copying/pasting.

Not sure if you saw this, but it might be useful: Websocket rate limit exceeded

19

Yep, saw that…
I’m look at @dsj’s post above (#6)…

Just sign in at tempestwx.com then go to Settings → Data Authorizations (or directly: https://tempestwx.com/settings/tokens ) and create an access token. Once you have a token, you can use it with REST requests and WS connections

With that in place, we (developers) should be able to allow a user to login and get/create the access token via code…

1 Like
20

Hi folks. First off, apologies for not having this authentication business all written up nicely in our API documentation, yet. We are still working on that (in between everything else). The good news is that we do have a system that’s working well in production. In a nutshell, here are the two options for user authentication in a third-party application:

  1. Personal Access Token . If you have a very simple app (like a python script or something your users download and run on their own) you will want to go the “personal access token” route. It’s a little clunky for the user because it requires him or her to sign in to our website, create a token, then copy & paste that token into your app. This method is currently only documented here on the forum (in this very thread), but it works great.

  2. Oauth2. If you have a more sophisticated app or just want to provide your users a slicker, more seamless integration, allowing them to stay in your app when they authenticate against their Tempest account, you will want to use Oauth2. This is the way our own integrations work (Amazon Echo, Google Home, IFTTT, etc.). Oauth2 can be complicated, but the primary requirement is for you to run a server process that can respond to a post from the Tempest system, or an app with a custom URL handler. This method is not publicly documented yet, but we are beta testing it (and it’s what CARROT Weather uses). If you want to be an Oauth2 beta tester, shoot me a PM!

4 Likes