Allow OAuth token authorization in webhooks

Smart Home & API
1

A couple years ago, I requested that webhooks support Basic authentication, at a minimum:

That was implemented, thank you again.

Our platform is making another upgrade, this time to enable OAuth authentication for our inbound webhooks. So, for example, when doing the webhook registration call:

curl -X PUT -H "Content-Type: application/json" -H "Authorization: Bearer 8e600a4c-0027-4a9a-9bda-dc8d5c90350d" -d '{ "id":"79667c29-bd07-428d-9c29-23e18b023978", "externalId" : "external company ID", "url":"https://www.mydomain.com/another_webhook_new_url","eventTypes":[{"id":"1"},{"id":"2"}]}' https://api.rach.io/1/public/notification/webhook

You could add the OAuth token:

curl -X PUT -H "Content-Type: application/json" -H "Authorization: Bearer 8e600a4c-0027-4a9a-9bda-dc8d5c90350d" -d '{ "id":"79667c29-bd07-428d-9c29-23e18b023978", "externalId" : "external company ID", "url":"https://www.mydomain.com/another_webhook_new_url","OAuth_bearer": XXX-XXX-XXX-XXX, "eventTypes":[{"id":"1"},{"id":"2"}]}' https://api.rach.io/1/public/notification/webhook

And then include that in the Auth header instead of the Basic auth that’s possible now.

2

I second this request. Passing the bearer token in the URL via the access_token poses a security risk… would be much better to have the option to send it in the header. I like the suggested implementation by @FlyingDiver.

3

What security risk are you referring to @ajostler? Full URL over https is encrypted, in a similar way a header would be. If you rely on plain http, than it’s just as venerable as a header would be.
For systems which cannot accept token via URL, then a custom header support would be desired, but if yours accepts it over URL, you are all set, as long as you are using a standard https encryption.

4

I don’t think there’s any way to provide a token via URL. There’s no standard syntax (that I know of) for embedding a Bearer token in the URL, as there is for username:password.

5

Thanks for the response, @Gene. I think you’re right about the security assuming the use of HTTPS. At first I didn’t think my system (Smartthings) allowed for authorization via URL, which is why I was hunting for a way to provide it in the header in the Rachio Webhook. However, turns out I had an error somewhere else, and I’ve now got it all working!

@FlyingDiver, the way to pass the token via URL is with the “access_token” key. Your URL will end up looking something like this.

https://base.url?access_token=bearer token

1 Like
6

Is this a recognized standard (like username:password) or just something that Rachio does? I will try this out tomorrow.

7

@Gene - I think @ajostler was confused about my specific request. This is NOT about authenticating to the Rachio servers, which the access_token in the URL seems to satisfy. I’m specifically talking about providing authentication information in the webhook, for authenticating to the webhook recipient. I can do that now with username:password in the webhook URL submitted to the Rachio servers. But we’re trying to migrate from using username:password to revokable tokens, so I need something that will generate a “Bearer” type Authentication header. Like the curl --oauth2-bearer option does.

8

Hey @FlyingDiver, I’m using it how you are describing to make calls to Smartthings. See below for the code that I use to create the Rachio webhook.

{"device": {"id":"{{Rachio_deviceID}}"}, 
    "externalId":"SMARTTHINGS", 
    "url":"https://graph.api.smartthings.com:443/api/smartapps/installations/{{ST_deviceID}}/rachio/?access_token={{ST_Token}}",
    "eventTypes":[{"id":"10"}]
}

I haven’t had much luck finding documentation on the REST standard for including “access_token” in the URL. However, I believe that it’s a fairly common practice. This is where I originally found the suggestion to use the “access_token” key.

And here are a few examples of systems allowing for authentication via URL with the use of the “access_token” key.

Google Firebase
https://firebase.google.com/docs/database/rest/auth

Marketo

As @Gene mentioned, not all systems accept the token via URL (which might be why you’re not having much luck). However, for me, it worked great. I agree with your original post, though, that it would be great to include the option to add a bearer token in the header.

1 Like
9

OK, I’ll discuss this with the developers of that part of the system. Maybe they can handle this in a future update.