I have not seen this addressed on the web, and I think it is something of importance. Right now, I'm building a product that will have an Android app, iOS app and also a website. A user could be simultaneously logged into each of these apps. This is something one could do with Twitter, Facebook, Google, etc.
There is an issue with the current paradigm though. The current paradigm for authentication for an Android app is passing an auth_token param between the front-end and back-end. When the user logs in, one gets generated. When the user logs out, the auth_token gets set to null in the database. If you were using this token to track sessions between an iOS app, Android app and website, you'd run into issues quickly.
The most common one: If a user is logged in via Android & website and logs out of the website, this will also have the side effect of logging them out of the Android app because the auth_token is now null in the DB, and there is nothing to match the auth_token being sent in by the request from the Android app.
I have thought of one solution, but I don't know if it is optimal or if it is the way this thing is handled in other large projects. If there is a better solution, do tell.
My solution:
Every request contains an Origin header. If it comes from the website, this header should hold the value Application. If it comes from the Android app, it should hold the value Android, and if it comes from the iOS app, it should hold the value iOS. This would require three separate DB columns. An auth_token for the web platform, Android platform and iOS platform.
If you decided to start supporting Windows phones, you'd need to rebuild your session handler for Windows as well.
That being said, this does keep the entire project and its constituents accountable and knowing of the fact that we're about to support a new front-end. However, it seems a tad problematic to me.
Is there a better way to do this? Is there a way most do this? Am I overthinking this? Am I wrong in my logic somewhere?
Is Devise an option for you? You can use it without Rememberable (http://rubydoc.info/github/plataformatec/devise/master/Devise/Models/Rememberable).
Related
My iOS app currently offers users the option to log in and sign up with their LinkedIn accounts. I am using this project for the LinkedIn log and OAuth: LinkedInOAuth
With the update to iOS 9, my app now occasionally crashes, when a user attempts to log in through LinkedIn using that project, with a runtime exception of WebThread(18): EXC_BAD_ACCESS(code=1, address=0x8)
To resolve this occasional crash, I turned to an updated version of the project I was using that conforms to ios 9 and linkedin's ios 9 SDK.
The issue is that while this new project has solved the WebThread crashing, it now requires users to download LinkedIn's app (if they don't have it) in order to log in to my app with LinkedIn.
The previous project never had such requirements and would present a webview that allowed anyone with a linkedin account to log in.
My question is am I wondering if it is possible to authenticate with LinkedIn in ios 9 without requiring the user to download the mobile app? My hopes are that it is possible to update the old project to conform to ios 9 while simply presenting a webvew. Thank you!
We only discussed this last week (at the time your question didn't have an answer, but happy to update you now—that is, if you haven't solved this in the meantime).
After scouring several sources I came across this:
Mobile vs server-side access tokens
Presently, there is no mechanism available to exchange them. If you
require tokens that can be used in both the mobile and server-side
environment, you will need to implement a traditional OAuth 2.0
solution within your iOS environment to acquire tokens that can be
leveraged in both situations.
from: https://developer.linkedin.com/docs/ios-sdk-auth
The premise being that via mobile solutions, they offer single sign-on thru their app. This works, but requires their app. Apple's approval process has swung both ways on this, and it appears that it is a flip of the coin as to whether they will allow this or not (the requirement of a third party app). #AroundThen didn't have any luck and his app was rejected due to the requirement, however, other users* have indicated Apple weren't adverse to it in their application processes.
Alternatively, their is the web logon process using OAuth2. This is pretty stock for their non-mobile solutions. Currently sharing the tokens between mobile and web solutions is not a default and if you want to share the same token their solution is that that is listed above.
In essence (and copied from my other answer here):
You can test for the presence of the linked-in app:
if it is not there: implement OAuth2 directly through your app
if it is there: use it or your OAuth2 implementation (which you'd probably err on the side of using their app for the link-ability between any features of the app you may need in yours).
Thereby avoiding the REQUIREMENT to have the app installed, but utilising it if it is.
This suggests that authentication away from the app is supported.
Reportedly, #AroundThen has had success with this process.
Good luck!
*1 I'm currently having trouble finding his post, but basically he provided login credentials that Apple attempted to use, but had locality issues and hence couldn't get in, but it was inferred they may have approved it if they had of.
Hello me and friends are planning on taking on a big project. My two friends are going to be building iOS and Android apps and I will be making the server back end. I recently started developing with RoR and have fallen in love with Ruby. Now here are my questions:
Little more background:
I only want a private API for the android and iPhone app. I do NOT want a full fledged OAuth authentication process. Doing some research I think I will go with basic HTTP authentication.
1. My App uses cookie based authentication meaning a cookie has to be passed with each subsequent request. So will my friends need to have to store a cookie and on each subsequent request to the server send the cookie along with it?
2. How do I go about making the API private? I know in OAuth there are consumer secret and consumer key. I know if anyone could simply figure out the URL schema they will be able to have access to the API. How do I protect my back end from request from unknown users? (Hard coding strings in the Apps themselves?, Checking headers for device type?)
3. Should I only build the API now and worry about a web app later? Or would it be too horrific of an experience to go back and build a web app (Although I really do actually want the web app to be more significant than the mobile app
Here is a great article explaining exactly what you're looking for : securing an API without setting up a full OAUTH provider :
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
Works great (even if the solution is finally not so far from oauth ;)
We have a web application that supports Facebook and Twitter login/signup via oAuth (and can also post to FB/TW). Now we are building a mobile client and naturally we want people to be able to login-signup via FB-Twitter on mobile as well, on iOS even using system-integrated accounts.
Now mobile app and our server app are two different apps, however, and if I get oAuth correctly, we'll need to have two authentications: one for a mobile client (system account can be used), another one for a server (we'll have to show WebView for it).
Yet some existing apps seem to be fine with single authentication only (e.g. Flickr and Foursquare! At least 4sq seems to be fine with iOS system FB account only. How is it possible?
Do they share consumer key/secret between mobile and web app making it essentially the same app?
Do they use some FB-specific extension to oAuth
Do they only use auth token wherever it comes from making it a user ID?
Something completely different?
Old question, but this may help someone who finds their way here.
Twitter Reverse Auth
I have a process that pulls all of the User's profile photos through a NET:HTTP connection. The problem is that I don't know if a user's account is using HTTP or HTTPS- the process works fine if I get this detail right. Is there a good, reliable way to have the Koala gem surface the user's security level?
I've been digging through the FB apis and cannot find any info on this. Hoping for some suggestions.
I resolved this issue by circumventing it entirely. I re-architected the applications to communicate with each other, rather than each making their own requests to the FB Graph.
The app that connects to the FB api dumps the content I need in the db, then a request is made to the other app (with the id of the new record). That app then calls back to the FB app, which provides a json service containing everything the other app needed from the graph. Completely eliminates http/https issues and authentication issues.
we are developing an iOS App using Adobe Flex/Air. The app uses a web service that needs user authentication via facebook login. At the moment, we use server side authentication: There's a login URL displayed in a WebView where the facebook login is done. This way, we get an access_token that can be used on the server side.
This works perfectly but it would really be much better if we could use Single Sign-on with the facebook ios app. As far as I have read, this should work on the client side but I haven't found a way to authenticate the user on the server side.
facebook's access_tokens are valid either for use on the server-side or for the client side so an access_token from the client-side login won't work for the server side.
Thanks in advance for your ideas,
Henk
As far as I can see, you're making this far more complicated than it's really intended to be. Leverage the Facebook iOS SDK, and all of the heavy lifting involved with authenticating the user within your app is handled by the Facebook SDK. There's no need to independently provide sign-in sheets and manage access token exchange between the app's local storage and Facebook's servers without the convenience of the entire Facebook SDK.
This link shows you how to implement SSO natively within your iOS app. It's real simple.
http://developers.facebook.com/docs/mobile/ios/build/#implementsso
Then, I understand that you're keeping authentication information or central user database information on an external server. The best way to synchronize the information between the FB client and your own servers is to simply check the login information returned by the FB SDK with your server after you receive it.
Here's a simple breakdown:
Log the user in using Facebook's standard SDK (see the link above).
In the -didLogin method (or whatever the equivalent is in your Adobe AIR environment), check the access token returned by FB with your server. Not sure what server architecture you're using, but it's safe to say that this will go on outside of the FB SDK. Also, save the access token in your app's user defaults so that the user won't have to login again next time. This whole process should (and inherently will) feel much quicker than it sounds.
If the check with the server returns successfully, notify the user of a successful login. If not, display an error view explaining the reason the user was rejected/not logged in.
Why do it this way? The reason is fairly simple. It's safe to assume that the reason you're having a user login to your app via Facebook is so that you can make requests for the user's Facebook information (i.e. feeds, photos, likes, comments, etc.). The easiest (and best) way to do this is through the FB SDK its self. The SDK takes care of a lot of stuff behind the scenes like access token validation over time, extension of token life, validity of token, and so on. This way, you won't have to worry nearly as much about syncronizing the server information and real-time client information when changes take place. Just authenticate via the FB iOS SDK, and do the rest of your own processing afterward.
Comment below if there's anything I should clarify or even if I missed the point of your question entirely--I tend to get on a roll and may stray from the point. :)
Cheers!
The Kraken