HTTP_AUTHORIZATION Bearer header missing, but is included in json?

I have created a Cloud Connector SmartThings Schema webhook and set up oauth so that a Django app on my cloud is receiving http POST requests from SmartThings. This is all working fine and my oauth provider is getting an access token, but when a call such as discoveryRequest is made to my api, there is no HTTP_AUTHORIZATION header in the request, even though it is in the json body. This is not entirely the end of the world as I can manually get the token from the json body and lookup the associated user in the database, but the oauth module (django-oauth-toolkit) actually expects this as a header.
I am not sure why this isn’t being sent, I have made similar webhooks for Alexa and Google Home and they do send the header. Perhaps I’m using the wrong oauth type?

Pretty sure you can get some help from @nayelyz !


Welcome to the SmartThings Community, @willemmerson!
I verified this behavior with our engineering team, they mention the authentication info is only sent in the Request’s body so, you’re on the right track extracting it from there.

body: {
    headers: {
      schema: 'st-schema',
      version: '1.0',
      interactionType: 'discoveryRequest',
      requestId: 'e99b644a-4900-...'
    authentication: { tokenType: 'Bearer', token: 'xxxx' } /*Token provided by your Oauth server*/

Remember to mark the solution of this post. In case you have more questions, feel free to post them here and we can dig in further.

I can get the token from the request body and this works, thanks.
However, I am confused. According to the official oauth2 spec (rfc6750), clients should send the token in the authorization header:

Clients SHOULD make authenticated requests with a bearer token using
the "Authorization" request header field with the "Bearer" HTTP
authorization scheme.  Resource servers MUST support this method.

In this case SmartThings is the client and our servers are the Resource servers, so if it’s not sending the headers then the SmartThings server isn’t oauth2 compliant.

What I’m confused about is that no-one else seems to have noticed this, I can’t be the first person to use this api, yet anyone else who tries to use this api with a standard oauth2 library should run into the same problem. But there are no other issues on the forums, which makes me think I am misunderstanding the whole thing! :thinking: