I want to create a chat application with two forms of login, a standard login form with username and password, and a secondary method using single sign in for logging in using facebook, but the user only needs to specify a username.
I'm planning on designing the application in two parts, a server side module which will be my own custom rest api, and an android application module.
I would like a way to authenticate the user from the server side. I was thinking of having the android application send an facebook api access token to my server, and then having my server check if it works for accessing their private data, but I'm unsure if this is valid enough proof that it is the original user. Is there a more standard way of checking if a the facebook user is who they say they are?
Related
I'm running a Classic ASP website, that has its own user authentication and login mechanism. For example, In order to remember a logged-in user, ASP creates an encrypted cookie and a 20-minute session for each connected user. If the 20 minute session is elapsed, the server revives the session from the cookie saved previously, and saves some data regarding the user to the database.
I want to to be able to allow users to connect with their Facebook or Google identity, but the mechanism used by Facebook or Google is based mainly on Javascript and on client-side code.
How Facebook or Google login can be used while maintaining server side code in ASP? (So that the ASP server can still manage the session and save data regarding it, for example whenever a session is revived)
For me somehow it seems that it may become less secure to use client-side authentication as the code may be altered easily. Isn't this the case?
If I use client-side javascript and log in with Facebook, how would I update the user data retrieved from facebook back into my database, for example the user's first and last name?
For me it sounds that it should be a "server-to-server" communication (between my ASP server and Facebook's or Google's servers) and what they propose is a "client-to-server" communication ... Any ideas how this can be done?
Any help or explanation would be very much appreciated! Thanks.
I'll try to address your Facebook-related questions one by one. However, I will not give you an implementation or any ASP-specific feedback, but only a rough approach. Additionally, I recommend that you study Facebook's documentation on Facebook Login extensively to further your understanding of the matter.
1. Facebook documents the server-side OAuth 2.0 flow in their Manually Build a Login Flow guide. Basically you redirect the user to a specific FB URL that (in the parameters) tells FB to render the "Login with Facebook" dialog, and which permission scopes to ask for. Once the user approves the Facebook Login for your webapp, they will be redirected back to your web app, e.g. with an OAuth token in the query string, that your webserver can then exchange for a user access token.
Once you obtained a user access token, you could e.g. store it in your web app user's session.
2. I don't know what you mean. Client side apps are fairly secure. Perhaps you can convince yourself about how secure JS apps are when reading about things like CORS.
3. If you only use JavaScript (e.g. Facebook's JS SDK) and you want to store e.g. app-scoped user IDs on your server, you need to expose an endpoint on your server that your JS application can submit that kind of information to.
4. You state
what they propose is a "client-to-server" communication
Who are "they", and where are the proposing this? The resources I linked to in 1. should explain how you can use Facebook login in a pure server-to-server way.
I've got a web app that currently allows users to login via Facebook. This is the only login mechanism at present. I make use of the user id and the users friends to perform certain actions. Now I want to create an api that I can use to create a native mobile app. To do this, I would need to authenticate users against the api. I've looked at this question
Possible approach to secure a Rest API endpoints using Facebook OAuth
but I don't actually have a "user" table as I only pull the facebook info when I need it. In iOS or something similar I could obviously make use of the native facebook sdk and then call my api, passing in the required user id and friend ids etc. however I'm not sure then how I could specifically secure my api so that if a user got hold of another's user_id they could in theory retrieve info via the api or in theory any resource that only specific users should be able to see
I thought about creating an app_id and app_secret for all the separate apps consuming the api. I would then use the appropriate secret to encrypt the data being sent and returned. The api and native app would know the secret and be able to decrypt it and validate that a user can view the requested resource. Does this sounds like a valid approach? In theory only the native apps would then be able to decrypt what is returned from the api. Or should this really be done on a user by user basis as recommended in the linked post?
All of this would be done over https
Thanks
Not familiar with the Facebook API nor iOS so I am speaking completely in theoretical terms.
Could you not:
Ask the user to login with Facebook on the iOS app
Send the login data over a secure channel to your web application to handle the actual processing of the data
Send the iOS app a secure hash for authentication
Use your web application as needed; using the hash for authentication, make HTTPS requests as you would your web application and use the responses from the webserver to populate the iOS app
If you make a user_hash column a complex salted hash like a SHA-256 (or greater) hash, the user_hash will become invalid before anybody is able to guess the hash. You could save the user's Facebook credentials locally on the iOS device and then renew the hash every so often, as to invalidate old hashes and lock out perpetrators (like how a cookie expires). If the user hash somehow becomes invalidated while using the iOS app, the app will send the locally stored credentials and retrieve a new one.
If Apple offers cookies for apps, you could send the hash in a cookie from your webpage and give it a reasonable expiry time (e.g. 1 day). You'd be resending the locally stored Facebook credentials every day and be effectively locking out anybody trying to bruteforce your hashes. Use that instead of trying to implement cookies from scratch (if the iOS API offers that), but as I said, I'm unfamiliar with iOS.
From an SQL standpoint, your webpage would validate a user's Facebook credentials, create a new row with a randomly generated user_hash, expires timestamp, user_id, friends_id, etc. Every user that uses the webpage will have to send the user_hash either from their web-client or the iOS app and will be checked against the database. If the present timestamp exceeds the expires timestamp, the session is ruled invalid and the user cannot operate your application.
Of course, you'd need to encrypt the communication. Do you pass credentials everytime the user loads a page on your web app? Or do you store them in a session?
Hope this helps at least somewhat!
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSHTTPCookieStorage_Class/Reference/Reference.html
I'm trying to build a Facebook-authenticated native mobile app (Windows Phone) that connects to a web service I am creating in Node.
I'd like for a user to:
Log in to Facebook on the mobile app via a native UI or web window
If logged in successfully, create or access server-side user account data tied to that identity
Use the authenticated session to make subsequent authenticated requestsvto that user's data via the native mobile app
My question is: What's the best approach here?
Should I...
Log in the client to facebook locally in the mobile app and pass the Access Token to the node service, and then somehow map the user to my service data based on their facebook account id? That seems grossly insecure if I just pass that token in the URL.
Log the user in via a mobile browser window inside my app, and then redirect back to my Node service in the same window? How do I then make subsequent authenticated requests natively in my app?
Do something else entirely?
Sorry this is so open ended but this is the first time I have tied these things together and although there's a lot of info on each part I've yet to find something that describes the overall pattern / best practice for this design.
Your question is quite opinion based...but still I will try to help.
First of all, you can pass access token in url, its not insecure if you use https. Even if logged into facebook from your mobile app, than also its going to pass a access token in url only. If you mean having the token in http://something.com/access_token, than its not how its should be done.
If you look into the Oauth 2.0 draft you will understand that its done through setting a header Authorization with the value being the token and token_type. Take a good look at the draft.
As your solution I think its fine if you just use the first method mentioned in the question by sending the access token in header as I mentioned in your app and in turn authenticating that token from facebook on each request.
If you think this is just too long a flow for authenticating every request from facebook, than you can get access token by sending request from your mobile app to server and let the server handle the access token and store it in database which you can authenticate each request.
In any case take a look at Passport module, it has facebook and other auth built-in and should be sufficient for your needs.
I'm not sure how to go with authentication method
I have a way but don't know if it is secure or not. let me explain what I'm doing with REST API.
I have a multiple users based web app, where users can login with their user name and password and do the stuff.
I need to develop a mobile app for that web app. I'm thinking REST with Slim Framework, However I have no
problem with Slim REST development but the authentication part is what I am not sure how to develop.
However I have some idea
Use session cookies :- When user login via mobile app call REST API authentication method, make database query
and match username/password. If they does match create two cookie for user name and password and store them in encrypted form
When mobile app send next request check the cookies, decypt the user name and password, again match with the database record
if matched call Requested method otherwise deny the access.
Please let me know how I am going?
Does it still make my REST API RESTful?
Is it okay to store username/password in cookies for above senerio?
I'm trying to create a server side access to a user's Facebook resources (photos/albums/etc).
I want that the user will authenticate once using its native mobile application, and that the server will be able to access user's data without the user interaction.
I'm trying to understand the steps I need to take in order to make it work.
I've read Facebook's: Login for Server-side Apps but I can't understand how to use the scenario proposed in there - because my server has nothing to do with user interaction (I cannot redirect the user to some login dialog) - the server is performing its own operation in the background whether the user is using its mobile application or not. What should I do upon token expiration for example?
More then that, I want that the user will be able to perform direct Facebook operation on the mobile itself, without the server intervention.
As I see it, this is the flow I would expect:
User's launches a native mobile application.
The user authenticates using Facebook's SDK on the native mobile app.
The user received a special token, that can be converted at server side to an access-token.
The token will be sent to the server and stored there.
If the server needs to access user's Facebook data, it uses this special token and converts it to an access token.
When the token expires - the server can extend it, using the special token, without any user interaction.
What data should be sent to the server from the mobile application after authentication. And how should the server use this data to access user's Facebook resources anytime?
I'm using the C# Facebook SDK for the server. But I think it is not that important, I need to understand the mechanics.
Tokens expire if the user does not continue to use the application. This is by design--an application should not continue to access the user's account if the user stops using the application.
When a user logs into your application, a token is given to your application, along with an expiration date for that token. You can use that token from your client or your server until it expires. However, there is nothing your server can do to extend the token if the user does not continue to use your application.
If the user continues to use your application, you will have an opportunity to update your server token. For example, in the Android and iOS SDKs, tokens are automatically refreshed if the user uses your application to make a facebook request. At that time, you can transmit the refreshed token to your server.