Anyone used this for Instagram

I don't think that anybody (besides me) gets notified when you create an issue. So, it is unlikely that you will get any answer about this. Try to ask to some other sites with more exposure, for example StackExchange.

I upadated this module to D8 to be able to use it with Instagram, and while testing, I discovered that Instagram does not return the 'expires_in' key. The expiration date for the token is set to the current time plus expires_in, and since expires_in is zero, the key is always expired. I set a default to expire in an hour in this case in D8, though I don't have enough experience with OAuth2 to know if this was necessarily a good solution. But maybe this fix should be applied to D7 as well, or some other method needs to be devised to handle the lack of this key in the response.

Maybe Instagram uses some other key instead of 'expires_in' (for example 'validity-time')?
Anyway, I think that this is a deviation from the OAuth2 protocol, and the best way to handle it is by extending the client class, like this:

  namespace OAuth2;

  class InstagramClient extends Client {
    protected function getToken($data) {
      $token = parent::getToken($data);
      $token['expires_in'] = 3600;
      return $token;
    }
  }

@Jaypan: By the way, I noticed that your code uses tabs (instead of spaces), and this breaks the identation for me. Would you mind converting them to spaces? I am not sure, but I think that one of D7 coding standards used to be not using tabs in the code; maybe it has changed in D8.

Maybe Instagram uses some other key instead of 'expires_in' (for example 'validity-time')?

No, unfortunately it doesn't send back any timestamp. I read that some other services don't as well, so it appears we can't rely on it.

By the way, I noticed that your code uses tabs (instead of spaces)... I am not sure, but I think that one of D7 coding standards used to be not using tabs in the code; maybe it has changed in D8.

No, it hasn't changed in D8. I have my own coding standard I use for my own projects, but I try to use the Drupal standard when working on other people's projects, I must have missed some spots or forgotten. Sorry about that, I'll clean it up and release a new version.

Wound up having to interface with the Instagram API in a current project. Per their authentication documentation, they do not include any expiry data:

Even though our access tokens do not specify an expiration time, your app should handle the case that either the user revokes access, or Instagram expires the token after some period of time. If the token is no longer valid, API responses will contain an “error_type=OAuthAccessTokenException”. In this case you will need to re-authenticate the user to obtain a new valid token.
In other words: do not assume your access_token is valid forever.

The solution in #4 works fine for me, and imo is completely reasonable.

I think that this is a deviation from the OAuth2 protocol

It's not, as the key is only recommended, not required: https://tools.ietf.org/html/rfc6749#section-4.2.2

expires_in
RECOMMENDED. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated.
If omitted, the authorization server SHOULD provide the
expiration time via other means or document the default value.

As it's not required, I think that the module needs a patch to handle the circumstance where it's not returned, as in with Instagram. I'm attaching a patch. If when it's approved, I'll alter the D8 branch to match (even though I already handled this case in a different method in that branch).

I've updated the 8.x-1.x version to handle this issue in the same manner.

@Jaypan Thanks for digging up the RFC (actualy I had never looked it up myself). I applied your patch.

By the way, since I am not able to test the D8 branch, you have total control on it. So, you can do whatever you think is right for it, don't wait for my agreement or approval.

On the D7 branch however I try to be a bit conservative with changes that I think are not necessary, since there are people using it, and having to update often is not a good thing (there is always the possibility of breaking things inadvertantly).

Yeah, I think we need to create automated tests for the D8 version before a full release is released, so as to prevent breaking functionality as we make changes over time. I do that with all my own modules.