I'm developing application which need access to user's facebook account. It is working, but I need to get user's facebook token and save it to MySQL database. How can I get facebook token using PHP (with permissions defined by me) ?
There's a good official guide/tutorial about just that in the facebook developers documentation.
What you're looking for is the Server-Side authentication flow, since it results with a long lived access token (60 days) which you can persist in your db and reuse when needed.
There's also the Client-Side flow but that grants you short lived tokens (a few hours long) which are no good for persistancy.
If however you do decide to go with the client side flow then you can extend the expiration time of a valid token using the new endpoint which was introcuded due to the deprecation of the offline_access permissions.
Related
I am working with API that uses OAuth 2.0. Its' flow is like this:
In your application, you have a button which redirects you to the authorization server (APIs' in my case).
You either have to log in to APIs' website and give access to your application (press "allow" or "deny" button) or if you are already logged in, just give access to your application (press "allow" or "deny").
You get redirected back to your application with your new access token for making API calls.
Everything works for me, all is good but what I do not understand is how to deal with given access token so that the user, which has already authorized access to your application, would not have to give access again. Etc when he comes back to the application after a few days. It gives bad user experience (no one wants to grant access again and again).
Note: I am working with Quizlet API
First of all, Access tokens should be short lived. Consider it equal to short lived one time credential. If you are not convinced, check Azure AD token life time definitions linked here "Configurable token lifetime properties".
Its recommended to use define short lived access tokens, for example which expires after 1 hour. That way you avoid the complexity of storing them. You simply keep them in memory and use them to access protected resources.
what I do not understand is how to deal with given access token so that the user, which has already authorized access to your application, would not have to give access again. Etc when he comes back to the application after a few days.
Well, here you should be talking about Refresh tokens. According to OAuth 2.0 specification, its refresh tokens which have longer life time. If you check with my earlier reference to Azure, you see that they can live up to 90 days. For Google, refresh tokens expire after 6 months (if they are not used). One can still revoke them.
Now when you are using refresh tokens, you are not using them to access protected resources. Refresh token should be exchanged to get access tokens. So if someone steal them, they still need client authentication (ex:- client id, redirect uri & client secret) to obtain access tokens. Still, protecting them is a must.
Regardless, RFC6819 define some possibilities you can take on in section 5.3.3 to store secrets (tokens are secrets). You may use a client storage mechanism or utilise server backed to store tokens.
If your application has an back-end, one possibility is to correlate cookies to tokens. Cookie value could be a hash of the token which you have stored in back-end(probably in a database). When the back-end receive a request with a valid cookie value, it can retrieve the token stored against it. This is quite similar to "remember me" functionality.
What if you can't control token life time (They are by default long lived) ?
If you can obtain tokens hassle free, and if you can compromise end user experience, go for in memory storage where you will always retrieve new tokens for fresh access.
If you have a back-end for you application which can maintain the state between clients, push and store tokens at the back-end. Correlate client session with tokens, probably through cookies/sessions. Call secure APIs through back-end, without exposing stored tokens to client application.
I am making an OAuth 2.0 request and it is returning me JSON with refresh_token and access_token, why are there are 2 in OAuth2.0?
Which one is short lived?
What is the purpose of both?
I read this question on SO but that didn'e helped me much, Any help in this regard will be appreciated
Thanks
The access token is what you will use to authenticate your service requests. It generally contains details about the user or is directly mapped to the permissions about the user and the permissions that he has granted.
These tokens are short lived - something like one hour, the actual duration differs per provider.
The refresh tokens on the other hand are used to get a new access token when the one that you have expires. They have a much longer (sometime infinite, until explicitly revoked) lifetime.
Now, let's consider an end to end scenario. Let's say you create an app that does Facebook actions on a user's behalf - post on their timeline etc.
Your app redirects the user to log in to Facebook - you use Facebook SDK for this.
When the user successfully logs in and gives you the required permissions (post on timeline) you get an access token and a refresh token.
Your app can now hit the Facebook API to post on the user's timeline on his behalf with the access token. This token can be used for one hour (or whatever time the access token is valid)
Once the token is about to expire, you can hit a Facebook API to refresh the access token, as this one is about to expire. So, you call into the API with refresh + access tokens.
The API returns a new access token to you - you can use this now till it expires.
PS - This is not how it happens for Facebook actually. This was just a random example to explain how refresh and access tokens differ.
If this makes sense, go back to the question that you have linked. It has some really good answers. :)
I am using the stock SDK for php/javascript. Now the app I am building many parts of it, if a user approves the use and accepts the permissions acts as a layer on top of facebook. Where it is planned to have my App pretty much interact with it as if the user was logged on at the time.
Previously I was playing with the offline_access but I recently read that that permission is coming out of the api completely and soon enough any tokens already in existence will just convert to 60 day tokens. I know from what I read that I can renew the tokens on a daily basis if need be when a user logs into my app. But my two biggest questions that I can't figure out one way or another is.
How do I ensure I get the "long-lived" tokens, and with these tokens do I store them on my end and pass them through the api to FB or is facebook storing these and through the use of the api the way it is and I don't need to store them somewhere. I know currently when I login it generates a token and stores it in a php session but the session is usually only good for the duration of the user being on my app. Note this is also a desktop app, not an app within facebooks canvas.
If I have to store the tokens to use them, and the php sdk bases itself off of whats stored in a session do I recreate the session with the stored access token for the user or I dunno, Im confusing myself as I type this out, hopefully someone can shed some light on the subject for me.
Here you can find some help on how to handle the expired tokens,
https://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/
And here more info on how to use the new method,
Facebook offline access step-by-step
All this matter always makes me doubt as well, but I have noticed that facebook usually keeps the token somewhere on the user end, probably a cookie, so that it will automatically connect. So I don't think that the token only lasts a session and I'd rather say you won't have too many problems with the depreciation of offline_access, though this might just be my personal opinion.
I've been trying to get Google's Calendar API working in a PHP web application, but I'm having a hard time getting authenticated.
What I want to do is to allow users to interact with calendars of a single account known by the server.
Each type of scenario covered in the OAuth 2.0 docs talks about "user consent" which involves a login form and the individual user logging in, but I want the server itself to authenticate directly and obtain an access token for itself.
Is there some part of OAuth or some alternative mechanism I can use to do this?
In order to do this, you must go through the steps for user consent and then copy the access tokens it gives you into the PHP code.
The usual procedure for OAuth is like this:
Send user to authentication page.
User comes back with $_GET['code']
Send $_GET['code'] to OAuth server for a token
Store token in database for the user (or session, if it's very short lived)
But when doing it with a single calendar like this, you modify step 4. Instead, you dump the token to screen and copy it into your PHP file as variables, instead of putting it in the database. Then when you go to pass the access token to the server, you just pass the known, static token rather than a dynamic token from the database / session.
See mathewh's answer here:
How to automate login to Google API to get OAuth 2.0 token to access known user account
The lightbulb for me is when you get the access token you get a refresh_token as well... you use this token to "refresh" your access token once it expires.
There is no way around a manual authorization step the first time.
I have gone through the google documentations for Oauth and AuthSub methods for authenticating and I've tried to google this without results.
For Facebook, you can request an access token which is of length lifetime, meaning you won't have to be requesting a new token every few weeks. What about Google, and YouTube in specific, is there any authentication method which allows you to use that token permanently?
In their documentation they state that they have long-life but no sort of additional detail, of exactly how long and whether or not you could actually get one which never expires.
Specifically, I am making an application that needs to login on a few accounts daily, but it is run through cron so there isn't gonna be a user logging it in each time, and I'd prefer not store the actual user/pass to the application itself and use the tokens instead.
Finally found it. They don't expire. You have to make sure to perform the last step, exchanging your single use token for a session token. That session token should not expire.
Here's what my step (using the Google AuthSub Client Library) looks like in C#:
sessionToken = AuthSubUtil.exchangeForSessionToken(authToken, null);
Simple enough. I'm sure it's probably something very similar for the PHP library. Just store that sessionToken instead of the authToken
Check out the AuthSub process flow. Specifically the very last step (#7)