I'm in the process of updating old demo code using an Echo and controlling Salesforce Cases (there's a vid of it here:
http://joshbirk.herokuapp.com/iot-controlling-chrome-salesforce-with-echo/) with the new Authorization Grant flow. It would be great to have the logic use a real user identity with a refresh token to keep it alive as opposed to a non-expiring API user that the current code does. I'm having pretty decent luck with the new flow, but I'm running into a few blockers: 1. The request from Amazon for an access token is formed in a way that Salesforce's token endpoint won't respond to correctly. If I'm examining the request correctly, it a) does not contain a Content-Type header and b) it is formatted in JSON and not form-encoded. We only support the standard (
https://tools.ietf.org/html/rfc6749#section-4.1.1) form-encoded and not JSON. FWIW, I still have to munge in our non-standard instance_url field into the access token, so even if this was changed I would still need a middleware layer until this flow could support optional fields like that. 2. For reasons I can't imagine, our login page breaks within the Alexa app itself. The submit button does nothing. The flow works fine from my desktop browser going to
alexa.amazon.com and I can't remember a time another mobile browser had this behavior. I don't know how to debug it since it's a browser within the Alexa app. This is more of a quirk than a blocker as I could direct users to the desktop to sign in (as you can see in the demo, it's likely they'll be in a desktop browser environment anyway). 3. The refresh_token is not sent along with the Alexa request, but I'm assuming that's by design and that the Amazon side is holding the refresh token for when the access token expires. But I'm not sure when that occurs, when it does the actual exchange. Is it based solely on the expires_in portion of the token response? It doesn't appear we send that over, but I could append in with the updates to the response I'm already doing (as I type this, I realize I can try this next to see if it works, if so all of these are more quirks than blockers :) ). Thanks in advance.
OK, I added an "expires_in" to the token response to Amazon from Salesforce. Now instead of getting an invalid session, Amazon appears to just stop adding the access_token to the user session once that time limit hits. So I guess my big question is: how is the refresh token actually being used? Right now I don't see a way for it to be exchanged for a fresh access token. Did that get attempted somehow from the AWS side and fail silently? Is there a way to see?
I think the solution I'm testing now should work more or less in lieu with the setup described in that blog post. I think I've fixed the refresh token issues but I'm doing some final testing now before putting code out there. I'm doing this in node, but the basic flow/trick I'm doing should be translatable to nearly anything running on a web server.