OAuth 2.0 does not define a User entity. However, we're providing an Entity\User class in this library. As a result of how various providers handle users and user data, we've had to modify this class numerous times to support each provider. Now that there are no more providers in version 1.0, it no longer makes sense to support a User entity that works for all the providers.

My recommendation is to remove Entity\User in v1.0. In its place, we should provide a basic Provider\UserInterface and possibly an abstract Provider\User with bare-bones functionality. Each provider will need to upgrade to use at least the interface by the v1.0 release. The management of user entities will now be the responsibility of each provider.

We should get feedback from each of the third-party providers for what the Provider\UserInterface should include.

Refer to #237 and #264 for more discussion on this topic.

• Eventbrite
  • [x] Find a maintainer
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
• Facebook
  • [x] Make a new GitHub repo
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
  • [x] Document any custom params
• Github
  • [x] Make a new GitHub repo
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
  • [x] Document any custom params
• Google
  • [x] Make a new GitHub repo
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
  • [x] Document any custom params
• Instagram
  • [x] Make a new GitHub repo
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
  • [x] Document any custom params
• LinkedIn
  • [x] Make a new GitHub repo
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
  • [x] Document any custom params
• Microsoft
  • [x] Find a maintainer
  • [x] Link in the README
  • [x] Remove from league/oauth2-client
• Vkontakte
  • [x] Find a maintainer
  • [x] Remove from league/oauth2-client
  • [x] Link in the README

You might notice Eventbrite, Microsoft and Vkontakte have been bumped off to their own repos. That's just some advice, but maybe @ramsey you want them to stick around and be official.

This is a backwards compatible implementation of HTTPlug. It provides an abstraction over Guzzle and other libraries sending HTTP messages. Using HTTPlug will comply with the dependency inversion principle.

With this PR we can now allow people using Guzzle5 using this library. This will also future proof us whenever Guzzle7 is released.

When dealing with an OAuth-Server which is not supporting the authorization with credentials inside the request body the Abstract- or GenericProvider is not directly working.

So you have to implement a new provider which is overriding the getAccessTokenOptions method.

It would be better if the AbstractProvider would stick to the recommended behavior from RFC 6749 of sending the client credentials using the basic auth (authorization header). As you can see this section also tells that sending credentials inside the body is not recommended and should be limited to clients unable to use basic auth.

The getAccessTokenOptions could look like this:

    /**
     * Builds request options used for requesting an access token.
     *
     * @param  array $params
     * @return array
     */
    protected function getAccessTokenOptions(array $params)
    {
        $options = [
            'headers' => [
                'content-type' => 'application/x-www-form-urlencoded',
                'authorization' => 'Basic ' . base64_encode($params['client_id'] . ':' . $params['client_secret'])
            ]
        ];
        if ($this->getAccessTokenMethod() === self::METHOD_POST) {
            $options['body'] = $this->getAccessTokenBody($params);
        }

        return $options;
    }

As the client_id and client_secret is still inside the params array, they are also still inside the request body, so they could be removed from the params if necessary.

Replaces Ivory HTTP adapter with Guzzle 6. Moves towards better PSR-7 compliance.

Also bumps the PHP version requirement to 5.5, because Guzzle 6 requires it.

Fixes #314

So I noticed that when authorizing a a code we do not validate that the state returned matches that generated within getAuthorizationUrl.

You see we generate the code here

    public function getAuthorizationUrl($options = array())
    {
        $state = md5(uniqid(rand(), true));
        setcookie($this->name.'_authorize_state', $state);

but within getAccessToken we do not validate it.

Was there any reason for this or was it just forgotten ?

So this library is very popular however it contains a lot of crap and legacy code that doesn't conform to PSR standards and isn't using good modern development practises like dependency injection and such. Also I've neglected this project far too long and I want to change that.

This issue is to track progress of v1.0 of the library which will be a top down rewrite of the underlying code but will keep it's simple API which people like. It will have some proper documentation too.

Here's the TODO list:

• [ ] Remove all of @TomHAnderson's code as per his request in #97 (as this is going to be a complete rewrite this doesn't matter anyway).
• [ ] Remove all of the build in providers and move them into separate repos - this way we can also keep issues for individual providers out of the main repo
• [ ] Write some quality documentation at http://oauth.thephpleague.com/

All work will take place in the WIP-v1.0 branch

Please feel free to add any additional thoughts/comments below and they will be taken into consideration.

It's been over a month since PSR-4 was put into composer so it's ok (since composer.phar self updates monthly) to move libraries over to PSR-4, and here it is.

For some reason I cannot get the email of my GitHub.

I tried to dig in the code did not find anything.

I even added the scope:

public $scopes = array('user:email');

I also tried:

public $scopes = array('user');

I get NULL.

It also seems that other information are not loading:

string(3) "uid"
int(--------) -> this works but I hid it.
string(8) "nickname"
string(5) "jnbdz"
string(4) "name"
string(19) "Jean-Nicolas Boulay"
string(9) "firstName"
NULL
string(8) "lastName"
NULL
string(5) "email"
NULL
string(8) "location"
NULL
string(11) "description"
NULL
string(8) "imageUrl"
NULL
string(4) "urls"
array(2) {
  ["GitHub"]=>
  string(18) "http://github.com/"
  ["Blog"]=>
  NULL
 }

I trying authenticate with oauth2-client, and give this error

 Catchable fatal error: Argument 1 passed to League\OAuth2\Client\Provider\AbstractProvider::prepareAccessTokenResponse() must be of the type array, string given, called in C:\wamp\www\stackexchange\vendor\league\oauth2-client\src\Provider\AbstractProvider.php on line 540 and defined in C:\wamp\www\stackexchange\vendor\league\oauth2-client\src\Provider\AbstractProvider.php on line 711

The code that i used is same of first example in this repository. Is a bug ? how i can to solve this ?

The User Entity for all the providers are tightly coupled and have no way to be injected or set when retrieving the user details. The only way now is to inherit the provider in our own concrete and override the method, which is not something i prefer.

public function userDetails($response, AccessToken $token)
    {
        $user = new User();

        $email = (isset($response->emailAddress)) ? $response->emailAddress : null;
        $location = (isset($response->location->name)) ? $response->location->name : null;
        $description = (isset($response->headline)) ? $response->headline : null;
        $pictureUrl = (isset($response->pictureUrl)) ? $response->pictureUrl : null;

        $user->exchangeArray([
            'uid' => $response->id,
            'name' => $response->firstName.' '.$response->lastName,
            'firstname' => $response->firstName,
            'lastname' => $response->lastName,
            'email' => $email,
            'location' => $location,
            'description' => $description,
            'imageurl' => $pictureUrl,
            'urls' => $response->publicProfileUrl,
        ]);

        return $user;
    }

In case of LinkedIn there are more user details we can extract when a r_fullprofile scope is provided. Are there plans to implement this and if not what are your thoughts about how to implement it? We could add it in the abstract provider but i prefer a seperate object for it.

Will free up some time, if needed, to implement it.

Bumps nokogiri from 1.13.9 to 1.13.10.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello, I installed the project via composer (2.6.1) and started using it as described here but found out that AbstractProvider.php no longer had support for PKCE when I wanted to use

$provider = new \League\OAuth2\Client\Provider\GenericProvider([
    // ...
    // other options
    // ...
    'pkceMethod' => \League\OAuth2\Client\Provider\GenericProvider::PKCE_METHOD_S256
]);

So when i navigate to https://github.com/thephpleague/oauth2-client/blob/master/src/Provider/AbstractProvider.php i can found setPkceCode(), getPkceCode(), etc... but not in the sources after composer install

Some OAuth2 clients also support OpenID Connect (OIDC.) Also, some native app integrations (e.g., Google) directly return OIDC ID tokens to the native app, which then can be used by a backend for SSO. You get the idea.

There are some other issues/PRs open for OIDC functionality, e.g. https://github.com/thephpleague/oauth2-client/pull/899, and those are good starts for sure. I think what is missing from at least that PR, and more generally, is the ability to represent tokens in a more abstract way. E.g., an OIDC ID token represents a resource owner, but does not contain an access token. This can also lead to some confusion like in https://github.com/thephpleague/oauth2-client/issues/976.

See also https://github.com/thephpleague/oauth2-google/pull/119 for the Google provider, which is an example of how these libraries can be augmented with ID token support to better serve as a backend for all types of SSO implementations, not just browser-based OAuth2 flow.

Pro Santé Connect is the french health services' OpenID/OAuth connector

The docs/ directory is what powers the website oauth2-client.thephpleague.com. Modifying links to work in the Github file browser will break the website. Please do not open a new Pull Request to "fix the broken documentation links"; they will be promptly closed.