I am trying to use the OAuth component in Settings to authorize with a service. The service only supports the clientSecret being passed server-to-server, and the oauth flow provided by OAuth component fails with an error.
If I try to use the OAuth component without the secret, then I get a different error. "Uncaught (in promise) TypeError: Cannot read property 'includes' of undefined".
In both cases, the onAccessToken callback does not get called.
Is there a supported way to do Implicit Grant Flow, which does not use the clientSecret, with the OAuth component? If not, how can I build my own flow? What API can I use to launch a url in a browser instance similar to how OAuth does it? I tried using a Link component with the source set to the authorization url (with query parameters), but it doesn't seem to do anything.
You need to provide a requestTokenUrl, clientId and clientSecret if you want to use onAccessToken, as we make the "server to server" request using those.
If you want to use implicit, we don't directly support it, but you can short circuit the oAuth flow, and you can use onReturn instead of onAccessToken, which will give you the data that was sent back from the oAuth provider before we do the above and request the access token. You could technically do implicit grant this way.
I hope this helps!
I'm not sure if it's related, but I am also having problems with OAuthButton which I haven't been able to resolve so far. I posted a thread about it a while back.
Which service are you trying to auth to, and which companion device are you using? Let me know if you get it working.
Fitbit supports the Authorization Code Grant and Implicit Grant flows as defined in RFC 6749.
If you want to use implicit, we don't directly support it, but you can short circuit the oAuth flow
Hey Jon. Been experimenting with implementing oauth into my clockface to ultimately consume and display data from the daily activity summary.
I don't think I'm trying to do anything unconventional. If switching to implicit means having to short-circuit the oauth grant flow just makes me think that it's probably not the way to go. Especially when we are talking about "fitbit to fitbit" communication. I assume you would recommend Fitbit OS apps use the auth code grant scheme for trying to communicate to the Fitbit Web API?
An example app showing the most basic implementation of a companion app fetching something from the Fitbit Web API would be hugely appreciated and would really help us in understanding the whole process. Surely a lot of fitness oriented apps will need to go through this process.
(Not that there isn't enough on your plate already!)
I supply all of those properties on the Oauth button, but I still get this error:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://app-settings.fitbitdevelopercontent.com' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled
This is coming from the url that I set in the requestTokenUrl property. When I looked this error up, it said that it was related to not using server-to-server communication, and suggested implicit flow as a workaround.