I managed to implement the Google Play Services API in my Cordova app (game). The game now sends the Google Play Services Player ID to my server when a person connects.
I am making a system that validates a user's permissions and sends them some data (an image from my server) if the permissions check out. So, I have the Player ID, but that isn't enough to validate that they are who they say they are.
I don't understand how to use Oauth2 to validate a user is who they say they are.
Stop me when I go off track:
Presumably, I would need a one-time token from them that I could then validate with, eh, "something", and then run a PHP validation function with that token and the "something" to validate that they are who they say they are.
I'm not sure how to request the token without having Google Play Services create an authorization window within my app, or what the code for any of it is. I saw some Oauth 2 things in PHP but they are positively gigantic things. I'm looking for something that can clearly explain how I can validate the user and a couple of lines of code for implementing it.
Ok, I think I figured it out. Basic concept...
1) User asks for access token for Google Play Services Player API. (requires an authorization dialog)
2) User sends access token to server.
3) Server sends access token to Google Play Player API.
4) If successful, server authenticates user.
https://developers.google.com/games/services/web/api/players/get
Edit: The above applies to HTTP only. Unfortunately, as far as I can tell, there is no built-in Android / Google Play mechanism to get an authorization code, only an access token.
i want to create an Api for my own mobile App to access data that is stored in a MySQL-Database. However i read a lot of articles about the 3-legged OAuth approach and i think this is not the solution i'am looking for. When i understand it correctly the 3-legged approach is more usable when for instance i create a new twitter client and want to use the twitter Api.
But my app is not a third party app, my app and the website incl. the database are from me. So i assume, that the user starts the app enters his user id and password, then the api has a function that checks whether userid/pw are correct and sends "true" as a result back to the app. The app then offers the user the possibility to access the functions for which a login is necessary. So the user should not be redirected to a website and "allow" the access to userid/pw.
If i understand it correctly the 2-legged approach is more likely for my purpose. But i am confused by this also. I assume that the user enters his id and pw, these credentials are looked up in the database by the web service a token will be looked up in the database for this user and will be send to the app. Additionally an app-token is saved in the app from the beginning and will be send with the request also. The app will save this user-token from the DB internally and will use this token everytime the user does something with the web service. With every request to the web service the token will be send to the service and the service checks whether the token is a valid one otherwise an error is send to the app.
I looked up this example:
http://code.google.com/p/oauth-php/wiki/ConsumerHowTo#Two-legged_OAuth
But there is nothing mentioned that the userid/pw from the user are looked up in the database...
Can anybody explain how i can solve this?
Two legged OAuth is similar to Client-Server. It is a client app requesting full access to the data from a server. The client would have full access to all data allowed by it's credentials regardless of which user is accessing the client
Three legged OAuth is a User-Client-Server. It is a Client requesting to get access to the User's data from a server. The Client would only have access to that an authorized user's data (until the user revokes access).
I'm working on an API and considering using OAuth (3-legged approach) for authentication and authorisation.
This is the basic idea:
In order for clients (mobile app or web app), to use this RESTful API the user will have to be logged in using identity providers/servers such as Google, Facebook e.t.c
Essentially 3 parties will be interacting here:
The mobile / web app: The one trying to access my API
The API: The site that contains data for the app to run
The identity server: The site that will allow the user to login in order to access the API
Now, the way that I understand this process (assuming I do). This would be the flow (summarised):
The user will try to access data from the API (consumer);
The consumer finds that the user is not logged in;
The user gets a page (with service provider buttons such as Login with Google);
The user clicks the button, and the service provider returns a login form;
The user logs in;
The service provider returns a page asking for specific permissions;
The user grants permission;
The service provider returns an access token to the user;
The user uses the access token to try the request again to the consumer (API);
The consumer takes the token and verifies it against the service provider;
The consumer grants access to the user.
First
Is this process correct (on a higher level), or have I completely misunderstood the whole thing. If it is not correct: Could you offer some tweaks?
Second
After this whole process. How does the consumer communicate with the user? Will I have to be passing around a token on every request made (between the mobile app and the API)? Or can I just use the user details from the service provider to identify the user?
Third
How exactly does the consumer (API) verifies the token provided by the user against the server? Is this already implemented in OAuth, or will I have to do it myself?
Forth and last
In terms of implementation, what would be the difference between the client (mobile app / web app) and the consumer (API)?
I'm new to this, and I am trying to implement it in PHP (the API). If you have any references to PHP code (sample implementations) or external resources, I'd really appreciate it :-)
I am also new for oauth but I'll try to help.
First you could look here for appropriate libraries which could help.
As for me your oauth flow is correct. A good explanations you can also find here.
Keep in mind that authorization server should return an authorization code which you use for obtaining access token.
So your questions:
1) Follow the second link and there - "Authorization Code".
2) With every request to you API you should send your access token. Something like
http://<your api>?access_token=7f813af1-381d-4dd7-b70b-b6a8399b2c00
3) Just use the libraries from the first link. I hope that they have already implemented this. :)
4)Can't exactly understand what you mean. Your client must be able to obtain access token, store it and send it with requests. Your API server must be able to receive access token from client, and give access to api if the access token is correct.
I'm working on a project which will use facebook authentication completely (no custom authentication implementation exists). Project uses PHP for server-side scripting. I looked around for implementing fast and secure authentication mechanism but i cannot find any detailed description about this subject. Facebook's documents are weak and does only provide basic information.
Which authentication method would be appropriate? There's a Javascript SDK and PHP SDK. As i understand, i have to use Javascript SDK for login, then using PHP SDK i will check my database for verifying credentials. But using Graph API with PHP SDK is slow. Is there a better way to validate session?
Will i need to check session server-side (PHP-SDK) on every request?
What I end up doing for my apps is pretty simple and relatively fast compared to any other method I've seen.
Check the signed_request if exists, parse it if it does. If it doesn't, set the $login flag to 1 in PHP
I check the user's session / cookie to see if the user was previously authenticated by the app (will come back to this later. If it is empty, set $login to 1.
If the login flag is set to 1, send the user to the installation url.
The user installs the app and is sent to a connector page. This page serves the purpose of getting an access_token and generating a session / cookie for the user. This means you won't likely need to check this access_token's validity for the life of the user's session. offline_access also creates new opportunities. You can store the access_token in your db as well.
Whenever you have a call that goes out to Facebook, check the exceptions, if you hit an authentication exception, clear the user's session and cookie. Next time it will force them to update their access_token, even if this process is invisible to the user.
I've done this on my apps, in most cases means I don't have to make queries to FB to see the validity of the access_token nor do I have to constantly get it on each page view. Our goal was to reduce latency on our apps, but Facebook was the biggest source of latency, doing this has cut it down considerably.
Answering my own question:
I used Javascript SDK for checking facebook authentication is available.
If fb authentication is OK and my application does not authenticated, i present user with a prefilled registration form of facebook.
If fb authentication isn't OK i present a facebook login button.
Registration Plugin authorizes my application and i call my fblogin.php to check this information using PHP SDK. When PHP SDK validates authorization, it stores this information on a session variable. So there's no need to check fb authentication on every request.
Login button does the same as Registration Plugin. These methods share same server-side functionality but their representation is different.
In order to catch facebook logout status, i used Javascript SDK to validate facebook authentication on every request. If user is logged out, my js code calls fblogout.php and current session is destroyed. There's a flaw on this method. If a user does not logout from my website explicitly, an attacker could do anything on behalf of user only disabling js on the same machine.
I cannot find a better solution with fast response time.
You can use one or the other or both.
You can use PHP SDK to generate the relevant URL's to send people to. And just wack that on a link.
Or you can use Javascript to make the Facebook Default login button.
After that you can use one or the other to maintain and verify the session.
I generally use PHP to do he grunt work with oAuth keys and use JavaScript SDK to make the nice Facebook buttons and some minor less important graph calls for session monitoring.
Anything that involves any heavy or multiple graph calls I push to PHP.
But there is flexibility there to do what you want. You don't have to use JavaScript SDK for login.
It's up to you if you want to verify every page load or not.
I tend to use the Javascript SDK to handle it and like Berk if the session is dead. Call a page redirect to a logout script.
As of the latest versions, PHP and JS SDK are now both able to access the same user session (login with JS or PHP [instead of having to do both]). Check out this blog post for a more detailed explanation and an example.
If you're worried about security, perhaps you could set the session cookie to expire sooner with session_set_cookie_params().
First, just remind you that you will need to save not only access_token, but ideally, you would like to save the user's facebook uid alongside with access token. This because typically, you will need to include the uid alongside with access token in your API call.
Second, from Facebook Documentation
Note: If the application has not requested offline_access permission,
the access token is time-bounded. Time-bounded access token also get
invalidated when the user logs out of Facebook. If the application has
obtained offline_access permission from the user, the access token
does not have an expiry. However it gets invalidated whenever the user
changes his/her password.
Third, the purpose of having access_token and uid, is to perform an API call, right? Start from there. Do the authentification, if only the access_token is (somehow) become invalid. How to check whether its valid or not then? Well, you can use cURL (Reference) or Proxy Library(but you may need to modify it lil bit, since it originally was written for CI) to make an API call as a validation proccess. Sample (*sigh, using my Proxy Library)...
// Suppose we are try to publish a status from our fb app
// $access_token hold the user access_token, which you saved into your database
// $uid hold the user facebook uid, which you saved into your database
$proxy = new Proxy;
// This is equal with perform regular HTTP POST request with cURL
$api_call = $proxy->http('post','https://graph.facebook.com/'.$uid.'/feed', array('access_token' => $access_token,'message' => 'foo'));
// Now we can validate...
// If the API success, it will be returned a post id, with json format
// if not, it will be outputing json like...
// "{"error":{"type":"OAuthException","message":"Invalid OAuth access token."}}"
// so...
$result = (array) json_decode($api_call);
if(array_key_exists('error', $result))
{
// Here you can perform an oAuth authentification, to get fresh access_token and update your database
// ...
// After it done, process the previous api call with valid access_token
$proxy->http('post','https://graph.facebook.com/'.$uid.'/feed', array('access_token' => $access_token,'message' => 'foo'));
}
The Facebook Connect documentation is rather limited. It doesn't really tell you what it is doing, only how to do it. I personally don't use either SDK. I have built my own framework for my development projects.
Both SDKs as well as the JavaScript in the tutorial are, IMO, fairly outdated.
If you want to stick to one of the FB SDKs here is my suggestion. Use the JS SDK only if your Graph API queries and the like are sent to a PHP backend via Ajax. Otherwise stick with the PHP SDK.
Introduction
Facebook uses oAuth v2. They describe two different methods of flow... Server side and client side. This would be implemented just the same as any other application authenticating against an oAuth v2 service. They both do the same thing. The only difference may be you can use 'code' as a request_type to get an authorization code for obtaining a token in the future.
Authentication
As far as FB Connect is concerned ll your script needs to to is make sure you have an auth token or auth code whenever you require authentication. If you don't have that then you need to get it. You can use the presence of an auth code or token as a condition for which FB button to show (login or logout).
Redirect the user to oAuth for authentication. Facebook has their oAuth implementation bundled in to their dialog API. More information on the oAuth Dialog here: http://developers.facebook.com/docs/reference/dialogs/oauth/
You can use the optional state parameter for something such as CSRF protection. It retains it's value after the process and is sent with the callback as a GET parameter.
Application Interaction
Basically you're going to write your application the same way you normally would. The differences would be:
Your user database no longer stores a password, just the FB UID. Also, according to the FB Dev ToS you really can't store any user information. If you want to store user information you need to get it from the user. You can populate this information for them with FB information, you just need them to submit it.
Your registration method won't have a form frontend posting to it any longer. It will be called when an authenticated user does not have an entry in the DB.
API Interaction
If you went with code instead of token you need to request a token by sending code. This is done with the Graph API oauth. This part is not documented at all other than in their authentication tutorial. http://developers.facebook.com/docs/authentication/
With your access token, whichever method you may have used to obtain it. You can now query the Graph API however you desire. This will return a JSON encoded object.
Conclusion
As far as a fast and secure implementation goes, the Facebook PHP SDK does the job. It handles everything I covered here, including the CSRF. How to go about learning it, I have yet to find decent documentation on it. Everything is either old or the writer doesn't really know and is going off of other tutorials.
Your best bet is to dig deep in those libraries and figure out how it works for yourself. Do some trial and error, experiment.
The way I learned was by writing my own framework for it. I suggest you do the same. You can extend the Facebook SDK classes if you like. It's really limited, but it gives you all you need. I took my most commonly used API calls and placed them in as well. I now have a very quick and simple end result that is driven from my library.
I think you don't need to implement SDKs.
1, You need to get permission from the user, to access his/her data. So you need to redirect them to Facebook. It is few (3-5) line of code in php.
https://graph.facebook.com/oauth/authorize?
client_id=YOUR_APP_ID&scope=email&redirect_uri=APP_URL
2, When the user arrive back to your site, come with $_GET['code']
http://YOUR_URL?code=A_CODE_GENERATED_BY_SERVER
3, You have to decode this code via Facebook get request, and get the access_token.
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
client_secret=YOUR_APP_SECRET&code=THE_CODE_FROM_ABOVE
3, After you have the access_token just run a /me?access_token GET request as often you need, to check the user is still there.
4, You can store the Facebook ID.
I think this is the fastest way. As far as I know the javascript sdk uses pop-up, what is blocked in most browsers.
This flow is detailed enough here: http://developers.facebook.com/docs/authentication/
i have looked over the internet on some information about this but all that i've found is for the SDK version 2.X.X, now with the 3.0.0 version it ain't working.
What i need is to get the user info and use it as a server to be posting anytime without rellying on cookies.
Any idea of how to do this? The old tutorials sugests something like this:
$facebook->getSession()
and on the sessions, i would get the keys but this method doesnt exists anymore. Any idea how to get the sessions keys and to re-use it?
Thank you!
If you need an "infinite" session, ask for the offline_access permission. From there, you'll have to take the access_token from the session and store it in a database.
The SDK provided by Facebook for PHP is intended to be called and utilized while a user browses your site - actions that perform facebook API calls without the users direct involvement require something more robust that uses the same approach but with saved tokens and initiated by cronjobs or background processes.
The oAuth 2.0 flow for validation and granting permissions is detailed in Facebook's documentation.
http://developers.facebook.com/docs/authentication/
You can perform the logic described here manually without even using the SDK using a standard HTTP request library like CURL. Basically what's entailed is sending a request to facebook when the user first looks to grant access, at which point the browser should redirect fully to the FB Login/permissions dialog. It is in this query that you specify what permissions you will require. You can use the redirect_uri parameter to point this back to an endpoint in your application that then takes the data Facebook returns, sends it back for an access token, and then saves that final oAuth token to a file or database row associated with that user.
For the kind of actions you have described, you'll need to request the offline_access permission when you make your URL call to Facebook. This generates a token that will be permanently valid until the user revokes its permissions in their facebook account using the 'Aps' interface.
You can learn more about oAuth here:
http://oauth.net/2/
I also highly suggest subscribing to Facebook's Developer RSS feed. They very regularly make huge shifts in how they operate their API and typically only announce them there.
http://developers.facebook.com/blog/feed