Twitter Stateless Session store not set on request. about providers HOT 29 CLOSED

from providers.

Hey,
@tremby great idea. I didn't want to modify directly the lib so I tried to modify my Controller, with success !

Here's a simplified sample :

BEFORE instanciate the Socialite Driver, add a cache key to the callback uri

$cacheKey = str_random(40);
config()->set(
	'services.twitter.redirect',
	config()->get('services.twitter.redirect') . '?key=' . $cacheKey 
);
$driver = Socialite::driver('twitter');
...

( in my code the cache key is set into a class property to use it after, but here I simplified a lot)

Then when redirecting, before that, take the session value and push it into the cache :

$redirect = Socialite::driver('twitter')->redirect();
Cache::set($cacheKey, session()->pull('oauth.temp'), 1);
return $redirect;

Finally, in the callback function, before obtaining the user, take the "key" in the request, pull the cache and store it in session :

if (Request::has('key') && Cache::has(Request::get('key'))) {
	session(['oauth.temp' => Cache::pull(Request::get('key'))]);
}
$user = Socialite::driver('twitter')->user();
...
`

from providers.

One potential solution which would involve cache but not session:

1. Generate a random temporary identifier for the current user when the log in request comes in.
2. Include this identifier in the oauth_callback parameter to the /oauth/request_token call to Twitter, such as by adding ?user=$tempId to the configured callback URL.
3. Read the response, which includes oauth_token and oauth_token_secret, and cache these, keyed by the identifier, for some short amount of time (perhaps one minute).
4. When the callback comes in, that identifier comes with it in a GET parameter. Retrieve the cached values, remove them from the cache, and continue logging in.

This isn't technically stateless of course, but it avoids use of sessions and therefore cookies.

I have some proof of concept code working which I hacked into Laravel Socialite. In vendor/laravel/socialite/src/One/TwitterProvider.php I have added:

// TODO: add stateless-mode-enabling code

/**
 * Get a cache key for temporary credentials.
 *
 * @param string $tempId
 * @return string
 */
protected function getTempIdCacheKey($tempId)
{
    return 'twitter-sign-in-temp:' . $tempId;
}

/**
 * {@inheritdoc}
 */
public function redirect()
{
    // TODO: if not stateless just do parent

    // Generate a temporary identifier for this user
    $tempId = str_random(40);

    // Add encrypted credentials to configured callback URL
    $callback = $this->server->getClientCredentials()->getCallbackUri();
    $this->server->getClientCredentials()->setCallbackUri(
        $callback . (strpos($callback, '?') !== false ? '&' : '?') . http_build_query([
            'tempId' => $tempId,
        ])
    );

    // Get the temporary credentials
    $temp = $this->server->getTemporaryCredentials();

    // Cache the credentials against the temporary identifier
    app('cache')->put($this->getTempIdCacheKey($tempId), $temp, 1);

    // Redirect the user
    return new RedirectResponse($this->server->getAuthorizationUrl($temp));
}

/**
 * {@inheritdoc}
 */
protected function getToken()
{
    // TODO: if not stateless just do parent

    // Retrieve and clear the cached credentials; complain if there are none
    $cacheKey = $this->getTempIdCacheKey($this->request->input('tempId'));
    $temp = app('cache')->get($cacheKey);
    if (!$temp) {
        throw new RuntimeException('No cached credentials');
    }
    app('cache')->forget($cacheKey);

    // Get the token
    return $this->server->getTokenCredentials(
        $temp, $this->request->get('oauth_token'), $this->request->get('oauth_verifier')
    );
}

Another way to do this which would shift the temporary sliver of state to the client side might be to use a short-lived encrypted cookie.

Any thoughts?

from providers.

+1 Running into the same issue

from providers.

Well I was waiting for feedback on what I posted above.

from providers.

From the link you gave:

Allows a registered application to obtain an OAuth 2 Bearer Token, which can be used to make API requests on an application’s own behalf, without a user context. This is called Application-only authentication.

I could be mistaken, but I believe that is not useful for Socialite.

from providers.

Are you using Socialite 3.0? People have been reporting that issue since using Socialite 3.0.

I hope I find some time to look into this soon but I am currently covered in loads. If people who encounter this issue could take the time to look into this that would be great since you already have a system running with the issue.

from providers.

Thanks for the reaction @faustbrian

I'm using Lumen 5.3 with Socialite 2.0.20 and Twitter Provider 2.0.2.

from providers.

I am also seeing this with Laravel v5.4.13 / Socialite v3.0.3 / socialiteproviders/twitter v3.0.0

Using Dingo API

The main issue is that stateless doesnt exist in oauth1 so either the main socialite package needs to be updated or the twitter provider needs some work.

from providers.

As I said I don't have the time to work on this the next few weeks because I am loaded with work so feel free to send a PR if it is super urgent.

from providers.

I am experiencing this too. If I set Twitter to stateless, I get

local.ERROR: Symfony\Component\Debug\Exception\FatalThrowableError: Call to undefined method Laravel\Socialite\One\TwitterProvider::stateless() in [filename]

from providers.

Has anyone been able to work around this in the mean time? I am also running into this issue.

from providers.

Did this ever work? If I understand OAuth 1 correctly it needs state for the token to be properly verified. If this was ever working, that would perhaps suggest that the check was not being made, leading to a security hole.

from providers.

You cannot use ->stateless() with the Twitter Socialite provider, as its based on Oauth1.

If you look in the Socialite directory you will find 2 folders: /One, /Two

All the providers in the /Two folder can use the stateless() method. Those in the /One folder, you cannot.

Twitter does not support Oauth 2 for user authentication, only for application auth, so this will never work unless Twitter adds API support.

This issue should be closed.

see: https://twittercommunity.com/t/getting-started-with-oauth-2-0/2338

from providers.

See this thread on the Twitter community forum, where a (former) Twitter staff member suggests the following:

The OAuth sequence doesn't require the use of sessions as far as I know. Since you can dynamically create your oauth_callback on the request token step, you can include everything you need to pick up state without a session by encoding it within the (signed) callback URL. Then when the user is redirected back to your site, the callback URL they land on contains all the information you need to identify them.

Does this mean it's safe to throw that (signed?) token in the callback URL? Would there be any security implications with this?

Could this be a solution to having a stateless option for Twitter auth?

from providers.

I just commented on that thread to ask for clarification and while doing so thought of encrypting the necessary information (oauth_token and oauth_token_secret?) with a secret known only to the app using Socialite (like APP_KEY), and adding this to the callback URL. Would this do the trick? I'm no security expert, but as long as you're using HTTPS it shouldn't be possible to intercept this, and if it's encrypted the user can't get at the secret to tamper with anything either.

from providers.

I tried to hack an implementation of the above together today, and I no longer think it's possible. From my comment on that Twitter community forum thread:

Looking again, I don't think this is possible. The callback URL has to be given along with the signed call to /oauth/request_token. And it's the response which would come back from this which has the data we'd need to encrypt and encode in the URL to statelessly retain it until the callback stage.

from providers.

@faustbrian, care to comment on why you closed this?

from providers.

Feel free to submit a PR and I will take a look when I have time.

from providers.

Hey @tremby, much thanks, your code works well. I think server-side caching is the best solution in this case.

from providers.

@tremby much tnx

from providers.

+1

from providers.

Will be support for OAuth 2 for twitter provider?

from providers.

Last I heard, Twitter doesn't support OAuth 2, at least not for third-party user authentication.

from providers.

It seems there is already availables Oauth 2 endpoints to be used. However, we will need a custom provider for that.
https://developer.twitter.com/en/docs/basics/authentication/api-reference/token

from providers.

@tremby you may be right. I just wonder if this provider has ever has been operative the time it was release despite the fact that it was using stateless method with OAuth v1 :/

from providers.

Facebook, LinkedIn, Google, GitHub, GitLab, Bitbucket and many others support OAuth2 for user-based authentication. but Twitter still using Oauth1 only .

if ($provider === "twitter") {
   return Socialite::driver($provider)
    ->userFromTokenAndSecret(
     env("TWITTER_ACCESS_TOKEN"),
     env("TWITTER_ACCESS_TOKEN_SECRET")
    )
    ->redirect();

Running into this issue :

Symfony\Component\Debug\Exception\FatalThrowableError
Call to undefined method Laravel\Socialite\One\User::redirect()

I want to be redirected into the callback :

https://mySite.com/api/login/twitter/callback

Any Help !!

from providers.

I just saw on Twitter Documentation that they support oAuth 2 here is the link: https://developer.twitter.com/en/docs/authentication/oauth-2-0

from providers.

@harshalone, see the messages above in this thread, from July 2018.

From the link you posted:

it does not involve any users

That's not useful for Socialite.

from providers.