[xmrcivicboix]

To temporary fix the issue, you could do the following:

change response_type=code to response_type=token. Instagram will redirect back to your site with something like /callback#access_token=123456. From here, send the user to a very simple page with the following snippet:

<script>

    if (window.location.hash && window.location.hash.indexOf('#access_token=') !== -1) {
        var accessToken = window.location.hash.replace('#access_token=', '');
        window.location = '/callback?access_token=' + accessToken;
    }

</script>

After that, you just use the Instagram API to retrieve user by access token then perform log in. This is not a recommended flow by Instagram but is a flow that works for now if your customers are constantly hammering you with support tickets as they did with us.

[goddamnyouryan]

Anyone have any experience getting this working with omniauth? It seems like one ought to just be able to change the config to:

    provider :instagram, ENV['INSTAGRAM_CLIENT_ID'], ENV['INSTAGRAM_CLIENT_SECRET'],  response_type: 'token'

But that doesn't seem to be working

[jontrausti]

Thanks for this temporary fix. Going to use it until Instagram fixes their issue with the authorization code.

[AlexWhite_]

This solution is insecure. Any person can intercept token and make harm to your application.

[xmrcivicboix]

I completely agree. Hence I said it's temporary. When you have a huge influx of paying customers who cannot log in to do their work, you have to balance that a bit.

[svens_]

It doesn't seem too bad when enforcing https (using the return address whitelisting in the developer console). Am I missing something?

[AlexWhite_]

Customer will see token anyway

[svens_]

Ah yes, of course. I did miss that. The implicit (client-side) auth flow gets the access token directly and doesn't need another request to the API, that's the whole point.

This is indeed rather unwanted, even more so with the new more restrictive API usage policy and the sandbox.

[vikaton]

Where would I change response_type=code to response_type=token?

[xmrcivicboix]

When you generate the server side explicit flow, it looks something like this:

https://api.instagram.com/oauth/authorize/?client_id=CLIENT-...

Depending on the library you use, it may be default to response_type=code. Just get the URL and do a search and replace if the library doesn't allow you to define the type.

See https://www.instagram.com/developer/authentication/

[vikaton]

I use this library: https://github.com/jaredhanson/passport-oauth2

Something tells me however that just changing it to 'token' (file strategy.js, line 217) actually fixes it, now there are other issues with many redirects when just changing that line, Im not entirely sure how that library works to fix anything else at this point, do you know when this issue might be resolved as a whole?

[xmrcivicboix]

Unfortunately, Instagram is terrible with responding to developer support tickets and there really isn't a much of a community aspect around it. This issue itself is not easily reproducible. The same account may work on one site and not a another site.

[AlexWhite_]

but this is better than nothing, thank you!

[vikaton]

How did you go about this solution?