I have an iPhone app that uses token based authentication whenever a user logs on with a Node backend. However, if that same user were to log in to the application from another phone I want to allow this but sign them out on the first phone. How would I accomplish something like this?
With token based authentication you would need to issue them a new token, and expire their old one(s). If a user attempts to access resources with an expired token deny it. This will require you to look up sessions by user.
Related
I'm writing an offline application that uses the Dropbox API. When a user comes to the application, I'm using the https://api.dropbox.com/oauth2/token (docs) to get a refresh_token, which I store for later use.
I am calling the same endpoint every time the user logs in (unless I've already got the user's data in a cookie). I'm not sure that this is the best way to go about it: I at least need to get the user's account_id, so that I can look up their refresh_token in the database if I already have it. But every time I call https://api.dropbox.com/oauth2/token, the user is redirected to the Dropbox app authorization interface, as if they've never approved the app before.
So I would either like to know how to stop Dropbox from forcing the user to re-authorize an app every time. Or, if that is just how https://api.dropbox.com/oauth2/token is supposed to work, I'd instead like to be able to get their account_id somehow when they visit my page.
(In case it's relevant, the app is still in development mode at this point.)
The https://api.dropbox.com/oauth2/token endpoint is an OAuth endpoint that the app can call to get an access token/refresh token. Being an API endpoint, it does not itself redirect the user to the Dropbox app authorization page.
The Dropbox app authorization page is at https://www.dropbox.com/oauth2/authorize (documented here), and the app decides if/when to direct the user there to authorize the app.
You generally only need to send the user through the app authorization flow (sending them to https://www.dropbox.com/oauth2/authorize and then calling https://api.dropbox.com/oauth2/token) once per user for an "offline" application. Once you do so, you should store the resulting refresh token for that user. You'll typically store the refresh token for that user tied to their user account in your own app.
Exactly how you manage the user accounts in your own app will depend on how it's built, but, as it sounds like this is a web app, typically you would use the user's browser cookies to identify the user when they return to your page so that you can look them up in your database and retrieve their details, such as their corresponding refresh token. (Or, if they're not already signed in to your web app, you would have them do so first.)
Greg's answer is very helpful, and very politely addresses my misunderstanding of the auth flow. (I was revisiting old code I'd written years previously—obviously I should have documented it better than I had!)
In the end I believe that Dropbox was forcing me to reauthorize because my application was in development mode, and had a small user base. When I used the identical code in an app set to production mode, it stopped forcing me to reauthorize. So the “problem” is really a Dropbox security feature, and the solution was just to use production mode.
I am working on my own app that uses instagram; but I think that this question is generalizable:
If my app determines that there is no auth token and requires the user to login; what should be done by the app in the way of cleanup after its done?
does it : leave the user "logged in" and let it be the responsibility of the user to invalidate the token ?
or: should the app basically leave things at the same base state as it found it? Going along with this reasoning; then it would require the app to keep track of weather it logged the user in or were they already logged in " valid authorization token" before the app was run ?
thanks
You need to implement a renew mechanism for your token.
Basically check that the token is still valid, otherwise delete it and unlog the user.
To unlog, simple, just delete the token (and user related datas).
If your app requires for the user to be logged in then you can just check if there is a token before displaying the related view.
Your user is unaware of the token (and everything related to it) and that needs to stay this way, period. If the token needs to be invalidated at some point, your app needs to handle it.
I am using tweepy api for oauth: http://packages.python.org/tweepy/html/auth_tutorial.html#oauth-authentication
The first time, user is ask to authorize my app. But from the second time, I dont want the user to be asked to authorize my app again.
The tutorial says
It is a good idea to save the access token for later use. You do not need to re-fetch it each time. Twitter currently does not expire the tokens, so the only time it would ever go invalid is if the user revokes our application access. To store the access token depends on your application. Basically you need to store 2 string values: key and secret:
auth.access_token.key
auth.access_token.secret
I plan to store access_token key and secret to a session. When user use my app the second time, I will just use the access_token, so user will not be forced to authorize my app again.
However, THE PROBLEM IS that what happen when many twitter users use my app, how can I know which access_token belong to which user.
I hope my question is clear.
Stop twitter to force user to authorize my app from second time.
if I need to store access_token to solve (1), how can I know which access_token belong to which user.
You need to implement session management in your web app and associate session IDs with your user model which stores the auth information. You don't say what language you are using but if you use the Ruby on Rails framework then session management is easily done. I recommend the Devise gem with omniauth-twitter (https://github.com/arunagw/omniauth-twitter).
I'm currently implementing an Oauth consumer service which is going to use Soundcloud as an Oauth service provider as well. But I'm having the following issue with it: Taking Facebook or Twitter example, you go there, you sign in, you fill up the permission form, and you are redirected back to your app. If you go there a second time, and given you are already sign in, you basically skip all steps and are redirected back instantly. That means, Facebook recognized that you already gave permission to that 3rd party service, so it doesn't ask your permission constantly.
And that's what's happening when I use Soundcloud. Basically everytime I redirected the user to the Soundcloud Oauth connect endpoint, the permission form always shows up, even though I already gave permission to that 3rd party service previously. I'm forced to press "connect" every single time, which is a drag from the user perspective (how many times can you give permission to the same entity). My question is: is there a parameter I can use to make soundcloud recognize/validate the previous permission from the user account to that specific 3rd party service? Or is this Soundcloud Oauth design implementation and we have to live with it?
Edit:
Maybe this wasn't clear, but each time I press "connect" in soundcloud, a new access token is being generated and delivered. Since my app uses this access token to identify its users, it doesn't work very well for me that the access token is getting updated everytime I want to log in, making me effectively "sign up" everytime. To sum it up, I want to get the previously attributed token to my account, so I can look up in my database, identify it and log him in.
I'm also looking for a solution which doesn't involve storing state in the client that might get cleaned up.
What you can do is store the user's oauth token in local storage and reuse it in future sessions. That's what happens on soundcloud.com.
A longer explanation:
When you use the Connect flow, the user is authenticated by SoundCloud (either by using username/password, Facebook Connect, or an already-existing session on soundcloud.com), and then when it is successful, your app is given an oauth token for that user. This is passed to the callback page which is registered for your app.
That token is the only piece of information needed to have the user be "logged in". Unless the token expires (by time, or by the user manually revoking it), then you can reuse that in future sessions.
I think I'm a bit confused about your application's design: where and how is the oauth token being used? I think that instead of using the token as an identifier, perhaps the user's permalink might be better? If you have the oauth token, you can find out the permalink by querying api.soundcloud.com/me.
So, I'm just starting to use omniauth and have gotten it working with facebook. I have set it up so that it automatically redirects back to facebook for a new token when the current token expires. Based upon that, is there any reason why I should be storing the token to the db? I currently log user accesses but don't really see any value in logging the token. Would appreciate any ideas on why I should.
thx
Depends on your business logic. For example, do you need to access the user's Facebook details at a later time, even when he is logged out? Or if you are queuing tasks (i.e. running this in the background), do you need to post to his wall a few hours later, instead of this very instant?
Another reason I can think of, is. Do you require your app to obtain a new token via Facebook all the time when the user needs to interact to Facebook via your app? Or would you like to store these tokens in your app, so the user does not need to go through the same process over and over?
It all depends on the kind of user experience you are trying to deliver.