I'm being asked if it's possible to have the ability to leverage facebook and twitter credentials by pulling account information from apps that are already installed and authenticated.
This means: an app is running and the user is logged in through FB or TW. Then, it launches my app. Could get those credentials and keep the user logged in on my app too?
I think this could be not so good to do it, but they are asking to me for an answer.
I did research and didn't find anything related, so I am thinking that it's not possible.
Could anyone confirm this or tell me how it could be done?
No, you can't. Each application must be registered on the respective social network, to obtain a application key and application secret. You then have to request a authorisation token from the server of the social network. Since the token is based on the specific application key and secret, even if you would be able to leverage this authorisation token (say on a rooted device), it would be useless to you, because you´d also have to know the key and secret. Ands Facebook matches the app signature as a extra layer of security.
Plain and simple no :)
If you just want to share data to Twitter or Facebook from your app, you should do this by using a share Intent. This way you push the data to whatever app (FB or Twitter, or others like email and messaging) while the user picks which app they choose to publish this data on. See more info at the developer blog here: http://android-developers.blogspot.com/2012/02/share-with-intents.html
And tutorial here:
http://mobile.tutsplus.com/tutorials/android/android-sdk-implement-a-share-intent/
If you want to do specific things with the authenticated account, like retrieve the user's timeline or wall posts, I don't think you'd be able to borrow that authenticated token from another app. You will have to register your app with each social network, ask the user his/her credentials and obtain a token. Then you can grab data from these services.
Related
Can you login user through your app without OAuth2 Server?
We currently use JSON Web Tokens.
Scenario:
User is already logged in the app.
Then he says "OK Google, openMyApp"
Then the bot asks him what does he want?
User says: "Reserve me closest car"
Because user is logged in the app, all it needs is Access Token from the app that is saved for example sharedPreferences.
Car gets reserved
This is the part that i don't know how to do. I read the documentation that the OAuth2 is needed for linking accounts. All we would need is the token, from the app then we know if he is logged in or not and because this is the service outside of Google, we would need a premium plan (pay as you go), to access our server. Thanks for the help.
Any thoughts?
No, there is no protocol for communicating between an action and an Android app for authentication. You may want to look at features like App Actions which will enable a closer connection between a local application and an action, or Google Sign-In which will provide a simpler authentication system.
There are mobile applications such as games where they allow the user to register and log in using Google, Facebook, or their own server. After logging in using third party provider, they seem to be able to store user information such as game progress to their server so it means that they can associate third party accounts to their user profile database. How do people typically do this?
I am using Identity Server as my main Identity Provider. It uses ASP.NET Identity to manage users. I have an android application which uses resource owner grant to get authorization token from the Identity Server. A new user can register a new account by going to the site where identity server is hosted.
Now I want to add a button to login via Google or Facebook within my Android Application. When a user logs in via Google or Facebook, the user information should be retrieved and then a registration form within the Android app will show with fields automatically filled up based on user information from third party providers. User can then register using that detail and save the user to the Identity Server with an identifier that that is a Google or Facebook account. Just like an asp.net identity site does it but for mobile.
Resource owner grant is a dead end here. You need to switch to a logon workflow using a browser. This will give you the external logins for "free".
https://vimeo.com/171942749
This is also encouraged for security reasons - see the spec I link to from the presentation.
I believe you can have a button that allows user to Log in using third party Identity server such as Facebook, Google. The only thing I am wondering is I am not sure if you will be able to make them register using those username and password.
The flow you can think of is:
Give the user an option of logging in as Facebook, Google etc.
User will get redirected to the login page for those third party services.
When they log in you will receive a token from Facebook that will have claims for the user and then you can do claims transformation and assign the token to your user.
Using the same token you can have the data stored in your database related to the user.
So in your database you will have 2 tokens, 1 from the Facebook and the other one that you will have for your own app.
The only option we can give is log in using Facebook. But by maintaining the information that the Identity server provides you can register the user on the back end directly so user don't have to register by himself.
We're developing a REST based API that developers would call from their mobile apps, e.g. google play apps.
How can we make sure that the app developer doesn't steal the users user/pass by storing them or sending them to "EvilServer".
If we do not trust the app developers, does a technical solution to this problem exist?
Could one solution be to have our own trusted authentication app on the native platform and let app developers use it to authenticate?
What I would recommend is to first remove the ability for a third-party application to log a user to your service using his credentials, so there is no reason for an app to ask for the user's credentials in the first place.
I would instead provide an OAuth authentication endpoint (take a look at the server-side flow) to third-party developers in order for them to use your authentication service to register and authenticate users in their app. This is interesting because users have to be redirected to your authentication endpoint when they log in, so there is no chance a third-party application can have access to their credentials at any point.
However, nothing prevents the developer of an evil app from creating a fake form requiring the user to provide sensitive informations in order to log them in, such as an email and a password.
In this case, you can do two things :
First, educate your users (e.g when they create their account) not to provide their credentials on any other website than yours. This is typically done by banks and insurance companies.
Implement Multi-Factor Authentication to add another layer of security to your authentication process. Most web companies such as Google or Twitter allow you to require that while providing your usual credentials when logging in, you are still required to validate the login process using an out-of-band medium. They typically achieve this by sending you a PIN code via SMS on your phone that you must input on a web page to finish the login process.
As such, if someone tries to log into one of your user's account, it will fail unless they have also access to the user phone.
OAuth attempts to solve this problem by sending the user off to a provider to authenticate before bringing them back to the original site or app. This is how the "Log in with Facebook" and "Log in with Twitter" systems work.
There's a handy diagram at http://www.quora.com/How-does-Login-with-Facebook-option-work-on-third-party-websites that shows how the requests are passed back and forth.
I am writing an Android app that makes calls to a REST Api. The user must be logged in and in order to do so, he must authenticate on the server which in turn redirects to the Identity Provider of my university.
My idea was to let the user log in via the android in-app browser and then extract the session cookie (and csrf, if necessary) into the app's AbstractAccountAuthenticator once the user is logged in.
How can I do this? I would also be happy about some helpful links. And secondly, is my way really the way to go?
In our application we provide user authentication possibility which gives him additional rights and functions. Now we need to add an ability to login into our application using social networks (Facebook, Twitter, Google+, LinkedIn). We don't need any functions of these networks.
I've read these articles about social networks authentication on Android:
LinkedId
Facebook
Google+
Twitter
All of these networks provide their own Android libraries which handle authentication process. I don't know if I need to use them (they have different APIs and seems to be quite "heavy"). I also found 3d party library which handles all of the needed networks.
Now what I don't know:
After user logs in into any of these networks using appropriate library mentioned above what do I have to send to OUR server to login him into our application? Is it OAuth token (but it seems to be valid only for mobile application which aquires it), SN user id, email or anything else (let's call it access token)?
After access token is sent to the server what server has to do with it? For example aftet successful login through any of SN user tries to use one of the features our application login provides. Each of these features needs server request. So when one of these requests comes to our server does it need to check if access token is still valid or it must just create our user instance once token comes for the first time and later it doesn't need it anymore?
Do I need to store access token locally on device or after it is sent to the server I can forget about it?
How to provide logout function?
Ok, I understand that this question may be not correctly formulated so please, feel free to ask for more info if you need it.