You could simplify things by using "password" grant type

[drdaeman]

Hubic seem to support grant_type=password as described in RFC6749.

This should allow to skip Mechanized HTML form juggling and exchange user credentials for OAuth bearer token in a single request:

> POST /oauth/token/ HTTP/1.1
> Host: api.hubic.com
> Authorization: Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=
> Content-Type: application/x-www-form-urlencoded
> 
> grant_type=password&username=user%40example.org&password=secret
> &scope=usage.r%2Caccount.r%2CgetAllLinks.r%2Ccredentials.r%2Clinks.rw

< HTTP/1.1 200
< Content-Type: application/json
<
< {"refresh_token":"foo","expires_in":3600,"access_token":"bar",
< "token_type":"Bearer"}

(Unfortunately, grant_type=client_credentials is not supported, so one still has to register an application.)

[vanicat]

The idea is great, but I did some test (first by using curl, then by changing my code) and it fail. If you have any indication about what idoesn't work with my code, I will be interested.

[drdaeman]

Uh, my bad. I've used sandbox client credentials (as listed on https://api.hubic.com/sandbox/, ID api_hubic_1366206728U6faUvDSfE1iFImoFAFUIfDRbJytlaY0), and everything worked with them just fine. Seems, self-registered apps are more restricted and aren't allowed to use this grant type.

I'm sorry, I was a bit over-excited when I toyed with API and sandbox test request worked so I opened the issue before proper and complete testing.

[vanicat]

It was what I feared.

But it confirm what I believe: if someone want to bypass the extra "security" given by the client credential, it just have to grab the sandbox ID and secret. Or to extract the ID and secret of any hubic official apps, it should be doable...

[vanicat]

I should have close this long ago, as it is no doable.