Hmm, I see @Rom. You need an extra step between 2 and 3, let’s split step 2 in 2a and 2b. Step 2a is the same as the former step 2 from your side, but with a different reply (http 200 iso 302). The extra step 2b is to mimic the form returned in step 2a, as if you pressed the Allow button, i.e. post the same parameters using form-url-encoding.
Something like this: _csrf=xxxxxx&resource=resource.homey.yyyyyyyy&allow=Allow
All the parameters are in the returned html from step 2a.
The seasurf (_csrf) is a bit puzzling to me at the moment, because it is in the returned html (at least that’s how it appears in my browser’s console) and it escapes me how this should prevent forgery. Another puzzling thing is that step 2a returns a csrf cookie with a different value. You might need to add the cookie from 2a to the headers for 2b, I can’t tell yet.
My code is running on an embedded system with a self-built https client that doesn’t support chunked compressed bodies yet, so I can’t test it at the moment. I hope to find some time next week to extend my https client and/or play around with curl and see what I can find out.
By the way, if you split the jwt from step 1 by the dots(.) and b64decode the middle part, you’ll get the id of the homey that you’ve logged in to (The y’s in resource=resource.homey.yyyyyyyy).
Hopefully this gets you going.
