Inconsistency or bug in authorize endpoint?

[nosh]

I've noticed an inconsistency in the results that come back from Shimmer's /authorize endpoint.
I'm building an device authorization UI in an external app, which is what lead me to discovering this

In my case, I've gone through the oauth flow and authorized two devices/providers:
Jawbone and Fitbit

When I call http://shimmer.xxxxxx.com:8083/authorize/jawbone/?username=tp|0e5fab3f1a
(i.e. get back authorization details for jawbone) I get back this from Shimmer:

{
    "id": "56292227e4b0682904230a4e",
    "stateKey": null,
    "username": "tp|0e5fab3f1a",
    "redirectUri": null,
    "requestParams": null,
    "authorizationUrl": null,
    "clientRedirectUrl": "oob",
    "isAuthorized": true,
    "serializedRequest": null
}

This is as expected - the isAuthorized field is set to true as the the device has already been authorized.

However, when I call http://shimmer.xxxxxx.com:8083/authorize/fitbit/?username=tp|0e5fab3f1a
I get back:

{
    "id": "56292336e4b0682904230a52",
    "stateKey": "c19cb2bf-9303-4f97-8573-9182849d963c",
    "username": "tp|0e5fab3f1a",
    "redirectUri": "http://xx.xx.xx.xx:8083/authorize/fitbit/callback?state=c19cb2bf-9303-4f97-8573-9182849d963c",
    "requestParams": {
        "oauth_token": "699018ef6491ead4cadf682507bca5a0",
        "oauth_token_secret": "6130fa167f49d2149cbec7d04cf14244"
    },
    "authorizationUrl": "https://www.fitbit.com/oauth/authenticate?oauth_consumer_key=1651ecdcf167d2a5928a5d243664f209&oauth_nonce=4705931066521466871&oauth_signature=3HaA0rk1cz5TgqxxRu0faHqVs44%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1445536566&oauth_token=699018ef6491ead4cadf682507bca5a0&oauth_version=1.0",
    "clientRedirectUrl": "oob",
    "isAuthorized": false,
    "serializedRequest": null
}

This has the isAuthorized flag set to false. This is even though the fitbit connection has been authorized.

When I call /authorizations for that user, I get back

[
    {
        "auths": [
            "fitbit",
            "jawbone",
            "runkeeper"
        ],
        "username": "tp|0e5fab3f1a"
    }
]

This leads me to believe there is something wrong with the /authorize endpoint. I'm not sure if it is specific to the Fitbit shim or some some weird state that shimmer gets into where it thinks that the Shim is not authorized (from /authorize) even when it is.

[schaefba]

Thanks for bringing this to our attention. We've looked into it and it appears to be an inconsistency in how OAuth1 and OAuth2 shims respond to requests to the /authorize endpoint.

In the interest of consistency, we will make changes for the OAuth1 shims (Fitbit and Withings) such that they will respond the same as OAuth2 shims. This means that they will not initiate a new OAuth exchange, in the case where the shim has already been authorized for that user, and instead will respond with 'isAuthorized' equal to true. This will match the behavior for the Jawbone shim, as you have described. We'll update this issue once the change is made. It should be in the next couple days.

We expect this to be a short-term measure as we will be making changes to the whole authorization aspect of shimmer in the near future.

[schaefba]

This issue has been fixed and released in v0.4.0 (commit 85aaebc).