I'm 100% for this as it seems to violate the spec.

The one single question I have is "what does this break"?

I just validated that https://tools.ietf.org/html/rfc6750 contains no explicit "expires" field, only the "expires_in" shown in the example in section 4, on page 10.

I just validated that https://tools.ietf.org/html/rfc6749 contains no explicit "expires" field, only the "expires_in" field.

From what RFC did this field come from? Or was it just a dev trying to add support for a product with lazy developers that uses the wrong fields?

Just want to point out that the build isn't working; I try to check on its status with this and I get a "we cant find your build" page. There may be a delay.

Previous issues #268 shown that it was added for Facebook compliance, however, requests-oauthlib seems to have fixtures for various OAuth2.0 providers already, including this expires bug: https://github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/compliance_fixes/facebook.py#L25-L27

So, LGTM !

Ok so to confirm: looking deeper this, its a compat fix for Facebook Engineers not knowing the RFC.

On a more personal note, this really bugs me. The difference is only 3 characters, but apparently big companies like FaceBook simply can't afford the top tier talent that can type that extra 3 characters for "_in" out to make the complete "expires_in" field name. Thankfully, they have the open source community to back them up. Thank you for your contribution.

So to recap our talks in the gitter chat:

1. Our teams very first priority is the RFC and keeping compatibility with it. Full stop.
2. As a special case: If the expires field exists in the requests and the expires_in field does not, backward compatibility code will switch it/help, but only if the expires_in field is not in the request. If the expires_in field is in the request, then the expires_in field is used no matter what as a priority, and in that case if expires exists its ignored. Fields in the RFC have priority.
3. We will need to add a info/debug line to detect the condition where the field expires_in is missing and the field 'expires' is not, and warn people that this is the wrong way of doing this, remind them that this may be removed in a future version of the software (as thats our goal) and gently guide them onto the correct path to use the correct fields. We should not allow this logline to be turned off as nudge in the correct direction.
4. Adding unit tests for these new conditions/tracking will be needed as part of this checkin before we can merge this in.
5. This may need to be wait until the build is fixed, depending on the unit tests provided.

Now waiting for updated CR that includes these. Thanks!

Referencing #524 as a placeholder for the build issue.

The other issues can be worked on concurrently.

Sorry to post yet again in this thread, but I wanted to update everybody that I created a new defect about this on Facebook's side with them directly, and gave them the link to this issue so they are aware of the defect in their code.

We should depreciate the workaround, but I think its even more important to call it out as a workaround in code comments, explaining exactly why it exists and highlighting the violation of the RFC spec on the part of the provider.

Since this is not backward compatible, shall we tag it for 3.0.0?

I agree, good to have but lets make this a non-compat release.

Anyone here think this needs further work before merge?