I am about to embark on adding a 'post to Twitter' feature on a web application.
It appears 3-legged OAuth is the only option for this. The developer documentation states however that "The user will always be prompted to authorize access to your application, even if access was previously granted."
https://dev.twitter.com/oauth/3-legged
This doesn't seem like a very good experience for the user and confusingly this is not what happens on services like Hootsuite. Have they organised an agreement with Twitter so users don't have to keep authorising the app?
Use the Sign-in With Twitter flow, and store the access token that the user receives when they grant access to your app. Then there's no need to go down the oauth/authorize route every time.
Related
I'm using Rails to write an API for mobile application and OAuth seems like a standard way to handle user authorization.
If I understand Doorkeeper docs correctly it requires user to be signed in with the website before it grants access for the mobile app.
The issue in may case is that there really isn't any website (it may be in the future but for now it's just api). I would like the user creation/signing in etc be handled in the ios application.
This makes me wonder if OAuth is the correct solution here?
The OAuth "Resource Owner Password Credentials Grant," according to rfc6749 Section 4.3, will grant an authorization token and optionally a refresh token given user name and password. Thus the mobile app doesn't have to store user name and password to gain authorized access. It becomes like a long running session using token and refresh token. OAuthClientSetup an iOS example that runs against a doorkeeper api.
So there is the OAuth method for gaining authorization without having web site login authentication and access grant.
What is left is how to register new users from your mobile app. Agree that does not look to be covered by OAuth. OmniAuth will let you register a user authorized by a third party site. You allow the user to be the user they are on Twitter or FaceBook, StackOverflow or GitHub or wherever else. Maybe that would help.
I'm creating an app for iOS that consumes an API I've created, which requires authentication and authorization of users. I'm thinking of using OAuth to let the mobile users do this with Facebook. This is an internal API that isn't meant to be exposed to third parties.
Anyway, I'm a little confused about the abilities and limitations of OAuth consumers versus OAuth providers. Basically, I want to implement "Login with Facebook" functionality from the iOS app. It seems to me that this implies that my API should be an OAuth consumer, but the problem with this is that the login flow for a web app assumes a browser -- an NSURLConnection instance isn't going to know what to do with an HTML login page, and even if the redirect to the login page was made to work by prefixing the redirect URI with the fb:// schema, surely the login form is going to pass the authorization token back to the iOS app and not my API?
So my question is: is there a way to implement my API as an OAuth consumer? If not, and I should implement it as an OAuth provider, what does logging in with credentials from another provider like Facebook even mean?
I think things are a bit mixed up:
OAuth is to Authenticate your app against facebook. A user grants
access to his FB account to your app on behalf of him
"Login with FB" is the other way round and is not OAuth: A User
with an FB account is using this data to register AND login to your
app.
The entire flow of the # 2 can be read here.
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.
I've been working closely with social integrations and the oauth framework for authorization. I know that, like Facebook, Twitter implements an oauth hook for its applications. My question is, is there a way to keep an access token active forever? Much like Facebook has its offline access permission, I would like to be able to only request that the user validate my app once (this is simply for an ease-of-use purpose).
When you implement OAuth for Twitter, you receive two tokens called OAuthToken and OAuthTokenSecret. You store these values in a settings file or a cookie or a database (or whatever) and then you use those tokens when submitting API requests in the future. This removes the need for the user to authorize the application every time.
Now, if the user revokes your application's permissions, then the tokens will no longer work.
I've read through documentation where possible but unable to figure out this basic question. When using Oauth with Twitter in my web application, does it require the user to be logged into Twitter everytime?
For example, if a user authorises their account with my website, in future sessions, if they complete an action that posts to their twitter stream, will this occur without any problems, or would they need to re-sign in via Twitter?
Thanks guys!
The OAuth authorization actually allows your application to access their account whenever it wants. So the users do not even need to be there doing something with your web application to allow it to tweet something or such.
Your application is then able to use the key and token which it received in the authorization process to tell Twitter any time "hey, I am authorized to use this account" and basically works as the application's personal login credentials for that account.
No, they only need to be logged into Twitter when they go through the initial OAuth authorization. After that, your site talks directly to the Twitter API using tokens that it saved from earlier.
Ok I've setup a test-case and it looks like I was a bit wrong:
oauth_token, oauth_token_secret are unique for each user and they never change, so if you store them in your database you can reuse them. No matter if the user is logged in to twitter or not.
No, they will normally not need to re-authorize. If the token is revoked, however, they will, and your application needs to be able to handle this (by allowing them to do so). In general, this is true for any SSO system.
A twitter user can explicitly revoke an application's token at the provided page.