Real-world examples?

So, here's what I want to do:

1) Give user a list of potential authorization services (Google, Twitter, Facebook, etc.) Allow them to click the button indicating this choice.

2) Then allow them to authorize at whatever service they selected and then return, storing their service choice and credentials in my database, along with their last_insert_id into a cookie for later retrieval.

3) Then, into the app.

I also want to check each time they log in for the cookie and if it exists, use the stored credentials to transparently validate if they are still logged in.

This seems like something everyone does but I've poured over the doc and looked for examples online with little or no success. I've tried six-ways-from-sunday to work in modified versions of the login_with_XXX.php. My latest was to try to jump out to the "login_with_XXX.php" directly.

I've spent a week and a half writing and rewriting. At this point, I could really use an a-z example. From presenting the authorization choice buttons ("Log In with Twitter", etc) to storing returned credentials and moving to their app.

Any help at all would be very, VERY much appreciated.

What you usualy can do is to allow to login with whatever social networks you want and then send API requests to get the user email address.

Then you check your site user database to see if there is an user with that email address. If there is, you start a session for that user.

If there is no user with that email address, you can create a new user record for that user and start a session for that user.

That is what is done when you login PHP Classes using any of the social networks.

There are a couple of details. One is that for instance Twitter and Yahoo do not provide the user email address. For Twitter there is nothing that can be done except asking the user to enter the email address.

For Yahoo, you can use the OpenID support. It is a different protocol but they provide the user email address that way. I have an OpenID client and server package that I never published but can be published if you need it.

The other detail is that the user may change the email address in the social network account. In that case, if you use the email address to identify existing accounts, you may not find the account. So it is good that you search first your user database for social network user id and email address second.

Thanks for such a quick reply, Manuel!

Initially, I was using Google's Oauth2 library (google-api-php-client) but the client needs to support multiple Authentication services.

Am I mistaken that we should be able to store the oath2 token and/or refresh token in the DB? What I want to do is to use Google (or Twitter, Facebook, etc. for that matter) as my primary authorization service. Only storing the #ID number from whatever service is selected.

Is this wrong? If I have that ID #, isn't that a good source for validation?

By default the class uses sessions to store oAuth authorization data. But sessions can only be accessed when the user is present.

You only need to store tokens in a database or some other type of external storage if you need to use the token to access the Google API when the user is not present.

If you just need to authenticate the user, he will be present when he authorizes your application access. So sessions are fine. There is no need to use a database to store tokens.

If you collect the unique user ID from Google, that is fine to locate a returning user in your database to determine if he already has an account in your system.

Just keep in mind that returning user IDs is not something standard that all OAuth based APIs can return to you.

That's a great point. I'll consider it as I go forward.

Now, I'm still trying to figure out the class. Here's a code snippet from the google login:
...
if(($success = $client->Initialize()))
{
if(($success = $client->Process()))
{
if(strlen($client->authorization_error))
{
$client->error = $client->authorization_error;
$success = false;
}
elseif(strlen($client->access_token))
{
$success = $client->CallAPI(
'https://www.googleapis.com/oauth2/v1/userinfo',
'GET', array(), array('FailOnAccessError'=>true), $user);
}
}
$success = $client->Finalize($success);
}
...

One question is this: How is anything below the

if(($success = $client->Process()))

line executed? As I dug into the class, it seems that the Process() method does a redirect, jumping out of the file right there. You hand things off to Google, which sets a code back to the file, starting again at the top. What's the magic that allows the CallAPI to happen?

CallAPI should only be called when the class as successfully obtained an authorization token. That is why there is a check to see if the access_token value is not empty.

The class uses the token to send the API call according to the OAuth specification.

If the token expires, the class may also renew the token transparently when you call the CallAPI function, as long as the OAuth server has provided a refresh token when the access token was obtained.

I am not if this answers your question.

"CallAPI should only be called when the class as successfully obtained an authorization token. That is why there is a check to see if the access_token value is not empty."

But doesn't Process() send the browser out to Google right there? I mean, the code below the Process() call is not executed once the redirect to Google is made, right?

Again, thank you so much for taking the time to help me out.

Hey, Manuel.

I found out that one of my checks was preventing the second-pass at the code, so upon return from Google, it was jumping over the code to process and make the API call.

Thanks for your help! No doubt it would have taken many more days of work to find without your feedback.


Scott.

One more thing.

Does your class support refresh token, as in Google's implementation of Oauth2?

Yes, the class can keep the refresh token for OAuth servers that return it.

If you need to call the API when the user is not present, keep in mind that storing token information in sessions is not suitable because sessions only exist when the user accesses your site.

So you may need to store the tokens in a database or somewhere that you can retrieve when the user is not present.

There are sub-classes that can help you to store all token data in a database.

This article explains better how it works:

phpclasses.org/blog/package/7700/po ...