Our web allows the user to publish tweets in his timeline automatically when he does some particular actions. However, a mobile app is connected with the web, an sometimes some actions the user does in the mobile app must be sent to the web app so it publish the correspondly tweet in the user timeline.
The problem is that the user can signin or login in the mobile app using Twitter and the user credentials must be sent to the webapp so it is able to publish in the user timeline.
Which is the best approach to share the user credentials between the mobile app and the web app?
I think the best way is to share your mobile app's access token with server, this is legal and works unless
the utilization of the access tokens is based on the same agreement the user gave you
That's an official answer from thread https://dev.twitter.com/discussions/4314. Another great citation from there:
Access tokens represent the relationship between a user account and application -- the IP address or host of the machine involved isn't relevant.
Related
I am trying to achieve the following:
an authenticated user uploads a video on my web application
my web app stores the video, logs it in our database etc. then connects to a Google account and makes a request to upload the video to a Youtube channel within that google account
I've created the Google account, enabled the youtube API, configured OAuth 2.0 access etc, but I'm not sure that any of the documented workflows meet my requirements. (For example I don't want any user interaction as part of the authentication process).
It looks like a Service Account ( https://developers.google.com/accounts/docs/OAuth2ServiceAccount ) is what I need, however these accounts dont appear to support all Google APIs, or at least not youtube.
Does anyone have any advice / has anyone implemented something similar?
When you say ... "For example I don't want any user interaction as part of the authentication process", how will that work.
The user might not be logged in to Google, or might be logged in to multiple accounts so will have to choose which account to use for your app. So the potential for user interaction is unavoidable.
Once the user has authorised your app, logged on to your app (ie. accessed it and you've stored his user id in the session), then future accesses will be devoid of user interaction; at least until he logs off.
The difference between service accounts and user accounts is not the auth flow. The difference is that with a user account, the API access is by the user via your app (so the video will be "owned" by the user. With a service account, your app IS the user (so the video will be owned by you).
I'm not saying that Service Account is wrong for you, just that your reason for going that way is not quite right.
So I've searched for this topic a lot and may be over complicating things but would love some clarity on it. So here's the issue.
I have a web app that uses Facebook Graph (FB Login, friends invite, sharing through FB, etc). We've just built an iOS app for the website and now want to implement all the above FB actions on the iOS app as well. I looked up the Facebook documentation and have tried using that to getting just the Facebook login to work for a user that's already registered on our website (and has their Facebook account connected as well) but it doesn't seem to work.
Use case - A user registers on the web app and connects their FB account with us. They then download the iOS app and want to use FB login to login to the iOS app or share objects on their timeline. A vice versa case should also apply.
Question - What should be the workflow between the ios App, web Server and Facebook for the use case above? Basically, how is the token and the secret passed so all three know we're talking about the same user and same FB account?
Any links or advice would be highly appreciated! Thanks!
In the case when a facebook authed webapp user first starts the native app, you won't know who they are. So they need to be prompted with a "login with facebook" button. When they hit that button, the facebook-ios-sdk will figure out who the logged in user is and then check if that user has already granted your application access. If the web app and the native app both point to the same facebook app, then the facebook-ios-sdk will simply store the authed access token, and you'll have access to everything your web app does on the native app.
The key here is that your web app and native app must point to the same facebook app (ie. same app id in developers.facebook.com). If it didn't, then the native app user would be re-prompted to grant permissions when they click the "login with facebook" button. Additionally, it's important that the user is logged into the same facebook account on the web app (which is based on cookies in the browser) and on the phone itself. The facebook-ios-sdk uses a couple of different ways to look for the active facebook account on the phone. It tries the iOS 5+ system facebook account, inter-app calls to facebook's own native app, the browser cookie for the web view instance running in your app, or bounce you out to safari and use the browser cookie in safari. Which ever one comes back first saying they have an active facebook account needs to have found the same facebook account as the one on the web app. In most cases, they will match up because most users only have a single facebook account and are logged in everywhere with the same account, but they certainly can be different. In the off chance that the web app facebook user is not the same as the native app active facebook user as detected by facebook-ios-sdk, then the "login with facebook" button will simply prompt the native app active facebook user to log in and grant permissions.
Once the access token has been granted to the native app, you can send it back to the server, find the associated facebook user id, and now the web app user and the native app user can be linked to be the same person operating both apps. Additionally, any graph api calls you want to make on the server can be made on behalf of the user using the up-to-date access token you just got from the native app. Any sharing/posting/api calls made directly in the native app through the facebook-ios-sdk will be done as this user and will be handled by the sdk (ie. you won't need to worry about it... it should just work seamlessly and integrate all posts to their timeline just like the web app's graph apis can).
In the case where you have a facebook authed native app user going to the web app, you also won't know (on the first request) who this user is. You can present them with a facebook js sdk login and, again, once the same facebook user logs in, you can associate this current web app user as the one who was on the native app earlier.
Specifically addressing your question, you really have no way of knowing who a migrating user is on either the web app or the native app when they first come to the app. That's where the "login with facebook" comes in. Assuming the user is logged into the same account on the browser as well as on their phone (as determined by the facebook-ios-sdk), then the process of logging into your app is seamless. They won't be prompted to grant permissions a second time (unless your permissions set is different between the web app and the native app) and you'll be given the user's access token immediately. The role of the server is to reconcile the two users by using the granted access token. With the access token, the server can make a simple call to the graph api and get the user's facebook user id. Using that facebook user id, you'll be able to match up the "true" identities of the users on your apps (ie. you now know that the web app user and the native app user are one and the same). Once you know who the user is, you'll be able to provide a personalized experience to that user, based on his identity, regardless of whether he's using your web app or your native app.
Hope this helps. Happy to answer more questions that you may have.
I am building a backend for ios apps, that support login in different networks.
Once the user login in to the network the client tells the news to the backend, and this could offer a list of worlds that the user might play, or even delete old worlds.
One way to steal another person's world is by saying that you are his social network id.
To solve that with facebook, we force the client to send us the fb_token, a token provided from facebook to the client, that we use in the backend to ask facebook if that specific user is the one that he told us to be.
If apple doesn't provide a way to validate this I understand that if an iOS app wants to use game center, it is directly forcing the app developer to also use iCloud because apple can validate the user credentials.
Did apple provide any way to validate user credentials?
The client on iOS can retrieve info about the currently logged in player in GameCenter, which has nothing to do with iCloud.
If you want to use iCloud to authenticate, you might have a different player than the one you wanted.
I think the solution is for the client to retrieve the player info in GameCenter, and send it to your server in an encrypted fashion (say HTTPS), including a timestamp and possibly other dynamic information. This way you'll know that the user info is being sent from the client app itself and there is no man-in-the-middle. That's really the issue that you are struggling with: how to ensure that client-server communication is secure.
Say that you have an iOS app, and a user that has one or more Twitter accounts set up on their device. Is it possible to load part of Twitter's mobile site into a UIWebView within the app with the user automatically signed in as one of those accounts?
Obviously, accessing the accounts would require the user's permission, which is fine. And probably after the first time, the site would remember the user anyway. But it would be nice to not force the user to enter their credentials again.
I know that I can use Reverse Auth to get OAuth tokens for an iOS Twitter account, but I haven't found anything concrete to allow me to exchange those tokens for authentication on twitter.com.
Well, according to Twitter's Taylor Singletary, it's not possible. Boo.
I have developed a PHP website where users authenticate via Facebook and I get and store their auth_token.
On the other side, I have started developing an iOS app where users will be able to authenticate via Facebook too. The auth_token, as you know, will be different from the one that I got in the website auth process (same Facebook app as in the website)
My question is: can I use the auth_token that I got in the iOS app to make requests from the website? (same user, same app)
The reason is that sometimes I want some actions to be performed from the mobile device (ie. update status) while others to be performed from the web server (ie. checking which friends of the current user are already registered in my website)
thanks
Essentially, as long as you have a valid access_token for the specific user you can use it anywhere you want. Anywhere that you can execute an http request to Facebook and provide the correct parameters, you'll be able to make API calls on behalf of the user.
https://graph.facebook.com/USER_ID?access_token=XXX
This call should work regardless of where you execute it from.