I'm trying to implement stateless redirecting to twitter from my Lumen app, but every time it gives an error saying: Session store not set on request.

I followed all the installation instructions of the Twitter provider correctly.

Although the provider should automatically detect I want stateless, I extra noted it in the call: return Socialite::driver('twitter')->stateless()->redirect();

Do you guys have an idea what might be wrong?

Guys,

Which plugin will work with Azure B2C? Looking at providers here all seem to use the URLs from Azure AD, but don't seem to work with AD B2C...

Anyone had a look at this before?

new provider had been added to build/split.sh by PR https://github.com/SocialiteProviders/Providers/pull/302

but new repo have not been auto created. 404: https://github.com/SocialiteProviders/WeChatServiceAccount

This starts to add Sign In with Apple support, and is based off of Aaron Parecki's blog on Okta.

I haven't been able to add the getUserByToken or mapUserToObject methods yet unfortunately as I can't find an API endpoint for this. 🤔

I thought it may be worth adding this PR and if anyone finds an endpoint for user data, this can be updated.

If it's better to just close this because of the lack of those methods, feel free to do so.

Since Instagram is changing the API, I needed to change some things. The tutorial is found here: https://developers.facebook.com/docs/instagram-basic-display-api

I tested it on my server and it worked:

1. Installation:

    // it's not added to packagist, someone needs to do it I guess? 
    //However, in future it's going to be:
    composer require socialiteproviders/instagram-basic

3. For the listener:

    'SocialiteProviders\Manager\SocialiteWasCalled' => [
        'SocialiteProviders\InstagramBasic\InstagramBasicExtendSocialite@handle',
    ],
   

4. Configuration setup

    'instagrambasic' => [
        'client_id' => env('INSTAGRAM_BASIC_KEY'),
        'client_secret' => env('INSTAGRAM_BASIC_SECRET'),
        'redirect' => env('INSTAGRAM_BASIC_REDIRECT'),
    ],

5. Usage

return Socialite::with('Instagrambasic')->redirect();

Hi team, MS Azure , provider class modified for API v2 compatibility. Added scope param (mandatory in v2 api) Added optional proxy configuration. Added logout url from Azure AD. bye

Using the Saml2 provider, v4.3.0 works fine, v4.4.0 breaks (some?) existing installations.

@27pchrisl

Invalid argument supplied for foreach() {"exception":"[object] (ErrorException(code: 0): Invalid argument supplied for foreach() at /opt/
librenms/vendor/litesaml/lightsaml/src/LightSaml/Model/Metadata/SpSsoDescriptor.php:110)"}

Currently when using Flickr it will result in the error: "Oops! Flickr doesn't recognise the permission set." - The authorize URL must have perms specified on it:

https://www.flickr.com/groups/51035612836@N01/discuss/72157692896948105/

Docs are here:

https://www.flickr.com/services/api/auth.oauth.html

I have verified that once this is added everything works correctly again.

Good afternoon,

I spent a bit of time this weekend trying my hand at creating my own Socialite Provider to try and integrate with the SSO software we utilize at a number of community colleges here in California (the software is from a company from the East coast however and is named PortalGuard).

PortalGuard supports multiple SSO protocols: CAS, SAML 2.0, and also OpenID Connect.

As I have been trying to wrap my head around what to utilize for my projects moving forward, I started reading up on Socialite and thought it might be worth a try experimenting with creating my own provider for PortalGuard (since after reviewing the other providers it seemed like everything in place with PortalGuard's OpenID Connect support should allow me to get things working...especially since a few months ago I was able to get the open source Kanboard project authenticating with its OAuth2 Provider and PortalGuard).

The main error I've been receiving has been the following one on my end:

Client error: `POST https://idp.example.com/oauth/v2/token` resulted in a `400 Bad Request` response: Bad Request

If I try with the stateless option instead it resulted in a different error, but the stateful approach seemed to be the better overall option.

I wasn't able to get it up and running though and wasn't sure exactly where the problem was.

As far as OpenID Connect goes, there's an older Laravel piece that seems like it might use Socialite a bit (last update is from 2017 however and the repo is archived currently): https://github.com/furdarius/oidconnect-laravel

There's a different OpenID type client here that's had more recent updates (but doesn't seem to target OpenID Connect specifically): https://github.com/univicosa/laravel-openid-client

There's a general PHP OpenID Connect Library available here that's also had recent updates (I experimented with this one a little bit, but it wasn't an option I wasn't able to get quickly up and running either): https://github.com/jumbojett/OpenID-Connect-PHP

At the moment, for SSO the protocol I've had the most success with has been CAS (via https://github.com/subfission/cas) but an option utilizing Socialite underneath the hood seemed like it might be a little more future proof / integrated into the normal Laravel capabilities, but that's a completely different protocol so wouldn't be something I could use with Socialite.

Any thoughts on whether an Identity Provider (PortalGuard in this case) that supports OpenID Connect can be used with Socialite correctly if a Provider is created for it? (At the moment I'm under the assumption that there's something wrong with the Provider class I put together, but since debugging details were slim it was difficult to say for sure).

Any thoughts on being able to troubleshoot the new Provider more effectively? (I do have a bit of insight into the requests in the PortalGuard logs on that end and share the following additional info).

Following the Socialite instructions, I added the following two routes on my end:

Route::get('/auth/redirect', function () {
    //return Socialite::driver('portalguard')->stateless()->redirect();
    return Socialite::driver('portalguard')->redirect();
});

Route::get('/auth/callback', function () {
    $user = Socialite::driver('portalguard')->stateless()->user();
    //$user = Socialite::driver('portalguard')->user();
    // $user->token
});

Primarily, I've been attempting to access the /auth/callback endpoint which I'm assuming should trigger a login flow on its own, but I never get to the PortalGuard login page. However, it does mark down some items in its log, including the following line:

2021-Jan-18 18:40:55.861919 [0x00001960] (i) IdPAgentOAuthToken::handleRequest(): Request _1234567891234567891234567891234 was missing code parameter

And I was looking at the Socialite code to try and understand where that code parameter comes from and it seems to come from the redirect() action, but I'm not sure why it's not being triggered automatically behind the scenes (or however it is supposed to work).

If I attempt to access the /auth/redirect endpoint directly first, it does correctly redirect me over to the PortalGuard Login page, and then I'm able to login, but then it seems to get stuck in a redirect loop alternating between these two requests primarily:

/oauth/v2/authz?client_id=987654321987654321987654&redirect_uri=http%3A%2F%2Fsocialite.test%2Fauth%2Fredirect&scope=openid+email&response_type=code&response_mode=form_post
http://socialite.test/auth/redirect?code=RANDOMLY-GENERATED-CODE

Thank you for any tips/insight you might be able to share!

There are 2 main problems in that provider.

Instead of api_key it should be client_secret as a key in config. Look here. She made PR for that, but it was closed.

https://github.com/SocialiteProviders/Steam/pull/4

Also there is problem with userFromToken($token) it doesn't work because inside that method a variable $token in not used, you can see it here.

The Steam provider depends on LightOpenID, which is abandoned. It is currently incompatible with PHP 7.4 and has pull requests open since 2016.

Error Exception on callback:

Function get_magic_quotes_gpc() is deprecated

From iignatov\lightopenid\openid.php:891:

$params['openid.' . $item] = function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc() ? stripslashes($value) : $value;

Because getUserByToken() is a protected function, you cannot check an identity token directly from the Socialite driver. This PR intend to allow the verification of a JWT by a public function, returning a SocialiteUser, or throwing an InvalidStateException when the given JWT is incorrect

Problem

I have metadata that includes multiple entitydescriptors for different authentication providers and the one I have to use is not the first one in that file. SAML2 driver only fetches the first descriptor and uses data from that so the login fails.

Solution

If user provides both metadata (url or a xml-file) AND entityid config values, then only fetch entitydescriptor for that entityid. If none are found or if entityid config value is not set then return the first one. It does not break current behaviour and supports situations where you have to choose the correct entitydescriptor.

What

The SAML2 provider does not honor the stateless configuration when used with the redirect call. This causes the SAML callback to fail as it does not exit the state check due to this and then fails as the SAML response may not contain state. It throws an InvalidState exception.

When

Whenever you attempt to set the redirect as stateless

Where

If you use the stateless configuration when producing the redirect:

return Socialite::driver('saml2')->stateless()->redirect();

The processing of the user data on the callback route will fail here vendor/socialiteproviders/saml2/Provider.php, line 444 due to this function at line 491:

    protected function hasInvalidState(): bool
    {
        if ($this->isStateless()) {
            return false;
        }

        $state = $this->request->session()->pull('state');

        return !(strlen($state) > 0 && $this->messageContext->getMessage()->getRelayState() === $state);
    }

However it pulls the stateless configuration, it is not seeing it as described in the Socialite Providers documentation here

How

I am not sure. I have not dug deeper to find out how exactly the stateless "state" is set and propagated.

OAuth docs: https://developer.huawei.com/consumer/en/doc/development/HMSCore-Guides/open-platform-oauth-0000001053629189

User info: https://developer.huawei.com/consumer/en/doc/development/HMSCore-References/get-user-info-0000001060261938