I have Oath working with Facebook, Google, and Twitter; however, I am having an issue with the latter where it uses an "authorization" URL each time rather than "authentication". The result is that the user is asked to authorize my app each time. With both Google and FB once the app is authorized they are not asked again when they log in. It is aware behind the scenes if the user is logged into one of those services and if so (and they already authorized my app) it logs them immediately into my app. With Twitter it will take them to an authorization screen each time.
I know this is due to the flow I have with Twitter which which says: redirect_url = auth.get_authorization_url() followed by a self.redirect(redirect_url)
The key above is "authorization" which is unaware of the user's acceptance of my app previously. In Twitter I know there is a checkbox to "allow this application to be used to sign in with Twitter". This is checked. What I am not able to find is the correct path with Tweepy that checks whether the user is already logged into Twitter and has already authorized my app.
I do save the tokens that Twitter sent back with the user at first authorization, however, I have no idea who the user is until they login so I cannot try to use these tokens for this initial part of the exercise. I should note that I don't have to use the tokens from Google or FB either at this stage.
Can Tweepy be used in the manner described above or do I need to do something else?
Thanks!
Fortunately, there is a very simple solution. When calling api.get_authorization_url, simply specify signin_with_twitter=True as a keyword argument. Your call should look like this:
api.get_authorization_url(signin_with_twitter=True)
This causes Tweepy to use the 'authenticationendpoint you mentioned, instead of theauthorization` endpoint.
Related
I am learning to use dropbox APIs and got confused when came up with the token flow.
As guide indicates, the flow should be like this:
the app redirect the user to a Dropbox webpage, i.e. .../oauth2/authorize
user logs in and approves the app
redirect back to the app. At this point, the app gets an access token.
However, when i requested the URL:
.../oauth2/authorize?client_id=xxx&response_type=token&redirect_uri=xxx
I was directly redirect to the destination with
REDIRECT_URI = "#access_token=xxx&token_type=bearer&uid=xxx"
And the "approve step" was skipped, i.e I got an access token without being allowed.
Is it a bug or my fault?
Any help would be appreciated :]
In certain cases, when the user has already approved the app to access their account previously, they will be automatically redirected through the app authorization flow.
If you want, your app can prevent this behavior from happening by using the force_reapprove parameter, documented for the /oauth2/authorize page here:
https://www.dropbox.com/developers/core/docs#oa2-authorize
I am developing iOS App which use Facebook iOS SDK 4.
When user has already done Facebook login, by doing Facebook login the dialog which shows "user has already approved your app" had be displayed.
So, do not show the dialog. I want to know whether the user has already done Facebook login.
Anyone know the good way? I think accessToken is returned if user once had done Facebook login.
FBSDKAccessToken manage current logged user's accessToken.
According to official Facebook Login guide
"FBSDKAccessToken Represents the access token provided by a successful login. Most important, it provides a global +currentAccessToken to represent the currently logged in user."
The currentAccessToken is a convenient representation of the token of the current user and is used by other SDK components (like FBSDKLoginManager).
According to above you can check either user has valid accessToken or not and based on this you can track call login method otherwise just skip to next flow.
In Facebook the access tokens are per user so you can pass them around apps and they will work. In your case if you can ship an access token from another app you will be able to skip the next logging in and use the API normally.
However I think this this thread will help you.
Things are a little bit different with iOS cause I have done a facebook login on Android and got no such issues.
*Apologies in advance for the long background but I think it is necessary and helpful to other devs once this is answered.
Background
I am building a very social web-application in which there are several events that trigger social actions such as updating the user's Twitter status.
Currently, I use a library called "TweetMoaSharp" (.NET) to handle the Oauth workflows and events that trigger a status update or follow action work brilliantly as long as the user is briefly redirected to the Twitter authentication page.
To clarify, the user is not asked to re-authorize my app each time, but there is an unsightly flicker that lasts for 1-2 seconds while the user is directed to Twitter and then back to my app. This will annoy the end user as there are frequent Twitter interactions.
So--to relieve the situation, I use TweetMoaSharp to obtain an OAuth Access Token via the server and then store that token along with the user id returned from Twitter in my database. I then set a cookie on the client that contains the user's Twitter Id so that for future requests I can simply pass that ID to the server, grab the OAuth token form the database and do my business. No redirect required!
Problem Solved, Right?
Well, no. Stupidly, I overlooked the fact that this can cause a collision with multiple Twitter Accounts being used on the same page and ended up tweeting test-tweets to a second twitter account I own because I had changed Twitter sessions. This could happen to any user(s) who access multiple Twitter accounts from the same browser; a husband and wife for example.
Back to the Drawing Board
I thought to myself, "The Facebook JavaScript API" makes it super easy to get the id of the currently logged in user without going through a bunch of server-side token steps so I am sure Twitter offers the same approach." Ha! I haven't found one yet.
Bottom Line / Question
How do I get the ID of the currently authenticated Twitter user without redirecting them to Twitter (even for just a second)? If I can do this, then I can compare the returned ID to the one in my cookie and know if it is valid for my application's current session or if I need to have that (new) user authenticate as well so that I avoid "Tweeting" under the wrong account.
Thanks in advance.
Use your app tokens to do a verify credentials call
https://api.twitter.com/1.1/account/verify_credentials.json
The returned info is the logged in user.
Unfortunately limited to 15 calls per 15 minute window!
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.
I am currently developing an app that will use the FB SDK (for the first time) to log a user into the app. The flow is typical, I assume. User taps "log in with facebook", facebook graph authenticates, then we do a call to our api and log the user in via their facebook email (only) we have on file.
However, whats freaking me out here is, theoretically if some knew our api_token, and knew that calling a POST to a login url with only a valid existing email to log them in, isn't that a security issue since they could actually log in as someone else. Am I over thinking this? Understandably, they'd have to know every aspect of the api to do any damage. But still, I'm not feeling comfortable with this flow. Am I missing something?
This shouldn't be something you have to worry about. Facebook first protects you by having the requirement for the user to be logged into Facebook. Next, the user's UID(readily available to anyone) and your API Key isn't enough. They'd still need your API Secret Key (which if someone has is a bad thing) to sign requests as you.
What you're really using is OAuth (though Devise, through OmniAuth). I'm not an expert but you can read more here: http://hueniverse.com/oauth/guide/security/
When a user registers via OAuth, you aren't going to have a password set for them, and that's not a huge deal as they have to also first log into Facebook. It might be a good idea though to ask them to set a password if they ever edit their account, that also means they can sign in the old fashion way if they desire/delete Facebook/etc.