AbstractProvider - Replace 'AccessToken' dependency with 'AccessTokenInterface' to support cases where AccessToken class is being extended.

[cloudcogsio]

A fatal error is thrown for the following case:

1. The concrete class League\OAuth2\Client\Token\AccessToken is extended by a custom provider. Lets call this 'CustomAccessToken'

2. The custom provider overrides the 'createAccessToken' method to return the 'CustomAccessToken' class instead of the League\OAuth2\Client\Token\AccessToken. (There should be no issue since base functionality is extended and implements 'AccessTokenInterface'

3. Methods such as 'getResourceOwnerDetailsUrl' will throw a fatal exception since it's declaration, although abstract, uses the concrete 'League\OAuth2\Client\Token\AccessToken' instead of the better suited 'AccessTokenInterface'

Fix: Replace all occurrences of 'League\OAuth2\Client\Token\AccessToken' with 'League\OAuth2\Client\Token\AccessTokenInterface' in the abstract methods of AbstractProvider.php

Changed in: https://github.com/cloudcogsio/oauth2-client/commit/07dd41cfaf8acfcb9e97844087c11ad0864cd42f

[cloudcogsio]

I've added a new Keycloak OAuth2 client with a branch that implements a use case for extending the base AccessToken.

See https://github.com/cloudcogsio/oauth2-keycloak/blob/master/README.md#custom-access-token-class

[ramsey]

Adding this for consideration to our v3 milestone. Thanks!

[pkly]

I would also like to see this happen, after updating some stuff and increasing the phpstan level to 7 suddenly I started getting a bunch of errors related to the facebook provider which takes an AccessToken object for getResourceOwner even though it's a perfect use-case for an interface.

What I would suggest instead is making the declaration for the abstract provider one that's based on the interface, but have the providers themselves tighten the type via @method annotations or overriding methods (safer).

That way one can't pass a twitter access token to facebook, for example, but the specific providers would still return some sort of token. One could create a dummy class, that'd simply extend AccessToken (from abstract) to create more specific return type, and then simply use said class in the provider itself.