I am trying to develop a simple PHP application that would fetch files via Dropbox API.
Problem is the authorization, which user has to complete every time one tries to run the script (after the session expires).
I was wondering if there was a way of obtaining some permanent access token via which I could login the once-authorized user to my app.
The access token you receive from /oauth/access_token after the user authorizes the app is actually effectively permanent. (That is, they don't expire for a very long period of time.) So, you can store and reuse the access token for future calls for the user without having them re-process the OAuth authorization flow each time.
One thing to note though is that the user can revoke access tokens (e.g., via https://www.dropbox.com/account/applications ) so be careful to catch 401 errors. If you do get one, it means the access token is no longer valid, so you should throw it out and prompt the user to re-process the authorization flow if they want to use the integration again.
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. :)
We are setting up a website, where users will fill out and submit answers to a surveymonkey survey. After the user submits his survey answers, we will access that data through an API call and generate a report for the user based on that data.
Everything works perfectly, EXCEPT every time I open a new browser and access the website, it takes me to https://api.surveymonkey.net/oauth/authorize?client_id=XXXXXX&redirect_uri=http%3A%2F%2FXXXXXXXXX%2Flogin_with_surveymonkey.php&response_type=code&state=1379358300-12fd31&api_key=XXXXXXXXXX (the X's cover identifying info), where I need to "Authorize user_name to use your SurveyMonkey account" ('user_name' is the SM-developer account login name). Once I input my SM account login and password, the website works perfectly and I can successfully do as many API calls as I want without any issues. However, if I close and reopen the browser window, I need to go through that tedious authorization process again.
Is there any way to permanently grant authorization to my surveymonkey account for my app, so that I don't need to go through this process every time I open a new browser window?
Thanks!
How are you storing the access token for the SurveyMonkey user?
Once you have generated an access token via OAuth for a particular SurveyMonkey user, that token will work until it expires (if it has an expiry time in it) or until the user revokes access. Only when that happens, i.e. you receive an error saying "Client revoked access grant", you should discard the old access token and reauthorize.
The access token is what you get back when you call through to /oauth/token (with the code retrieved from /oauth/authorize).
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 need help with Facebook OAuth. I am trying to make a facebook news feed gadget for my webpage. What I did is, I created a facebook login page, got the verification code, and then got the access token. There is an expiry parameter in the access token.
My question is, what happens when the token gets expired? Does it become a new token person logs in again. I want to store it in a database, so I can access it anytime I navigate through the webpage.
If I use the access token, will it still get expired? Or does it expire if its not been used for the given expiration time?
The answer to your initial question, is that an access token is only valid whilst the user is logged in. So yes, a new access_token will need to be retrieved every time they log in to your site. This is detailed in the authentication flow documentation.
In order to get an access token which is does not have an expiry (or has a long validity period), you will need to get the user to authorise the offline_access. This should be set in your scope.
Here's a description of the offline_access permission from this documentation:
offline access - Enables your app to perform authorized requests on behalf of the user at any time. By default, most access tokens expire after a short time period to ensure applications only make requests on behalf of the user when the are actively using the application. This permission makes the access token returned by our OAuth endpoint long-lived.
This will not however, give you access forever. If the user changes their password, or deauthorises your application, you will need to get the user to reauthorise it to get a new access_token. If you try to use an out of date access token, an error message will be returned. That's why it's important to have a flow which will allow for such eventualities.
From my knowledge you can achieve this by asking for access my information anytime permission (offline_access) while a user does fconnect.
For Detail information please refer
For Permissions: http://developers.facebook.com/docs/reference/api/permissions/
For expired Token: http://developers.facebook.com/blog/post/500/