I am using Facebook login OAuth for my app. The reason behind posting this question is uniquely identify the Facebook id , by using userID or access token.
The data will be stored in a database, and should be uniquely identifiable for that Facebook logged-in user.
The currentAccessToken does change and we can configure a notification(FBSDKAccessTokenDidChangeNotification) when it changes.
So, I confused, that should I use userId or accessToken.
As, in case if user deletes the app. and wants the data back for the app. there should be unique identifier for that user.
So, will the following flow work or am I missing anything.
The data will be stored in a database, and should be uniquely identifiable for that Facebook logged-in user.
Use the user ID then. Your login flow seems fine.
Note that there are multiple ways of do this.
The client logs in and sends the access token to the server, then the server fetches the data.
The client logs in and fetches the data, then sends the data to the server.
You'd want to use the first method if the data needs to be reliable.
Related
I have an iOS app written in Swift where I want to limit each account to one device only – what is a way that I could go about limiting this access? I'm using Firebase and have a login system but the login system is not linked to Firebase Auth.
After login the use generate the token and save them into dataBase. And send this token in header when you hit any other API. If new same use login on other device, update the token in data base .
Now you check this token is same or not if not then send repose code 401 and logout the user.
One option that also works, that I found through research, is to store the uid of a device in the database used in the app (or in NSUserDefaults) via UIDevice.current.identifierForVendor!.uuidString. Then, when a user logs in, compare the uuid with the device's uuid and take the appropriate action.
This is not foolproof – if the user uninstalls the app and re-installs it, they will be assigned a different uuid. But in general, this is the best approach.
I'm studying how to develop an iOS app and I need to figure out how should I structure it.
Architecture:
I've an external database, a REST api (as interface between the database and the app), and the iOS app.
The question:
I'd like users to authenticate by a simple form or by a Facebook login button but in each case a table 'user' in the database has to be filled with default fields like name, surname, email, profile picture, password(?).
For the standard authentication there are no problem, but for Facebook authentication I'm quite confused about theory:
Should I use access token? How?
When a user get authenticated with Facebook I haven't his password, so how can I get his informations from the database? In the standard way I would give to the database username and password and it would return for example the id field.
Sorry for my english.
You can use the access token of current logged in user
[FBSDKAccessToken currentAccessToken]
and send it to your REST api. From there you can retrieve every information you need and save it to your database (except user's password of course). If a user sign in for first time in your app insert a new user in your database and save user's Facebook User ID.
The whole idea of using authenticate and authorization is not to have access to user's password of another app, but the user authorize (confirm) your app to have access in his/her account with specific permissions.
Here is a step-by-step answer of what you need:
Design for Facebook authentication in an iOS app that also accesses a secured web service
You need to save the currentAccessToken that the login request returns to you.
Then, using Facebook's Graph API, the userID that was returned in the login request, and the user access token, you can request a user object, which has the email address, assuming you added the email permission in the login request.
Also use the Graphi API to retrieve the user's photo using the userID that was returned in the login request:
50x50 pixels
<img src="//graph.facebook.com/{{fid}}/picture">
200 pixels width
<img src="//graph.facebook.com/{{fid}}/picture?type=large">
I have a website where users can create an account and log in. This is stored in a database on the server. I also want users to be able to log in with Facebook etc, and thus skip the account creation. I don't know how to combine this and keep it persistent in the database. Any good examples on this use case?
Let's first see how logins work in general. When a user is logging in for the first time, a session id is generated for the user and is stored in the browser of the user as a cookie (note that there are mechanisms to store session id without a cookie, but let's assume you require a cookie for simplicity).
For subsequent requests to other pages in the same website, the cookie is also sent along. With this cookie (which has the session id), the unique user can be identified.
So, all that you require to know to identify a user in the server side (upon a web request) is the session id.
Having said that, if you want to include facebook etc into the login mechanisms, you need to do two things:
Connect your website with facebook (you will require a facebook developer account and some keys. Look here). When you do this successfully, if the user selects facebook login, your website should redirect to facebook login page and once the user logs in into facebook account, facebook will redirect back to your website with a token. This token is an indication that the user is a 'real' user. If required, you can use the token to get more details (such as facebook id, email address, name, etc.) from APIs facebook.
The second step is the same for any authentication flow. You need to generate a session id for use by your server and then save the session id in cookie.
What I have specified is the general flow on how your requirement could be achieved. The mechanics of how to do this will depend on the server side technology that you are adopting (such as ASP.NET, Ruby, etc.)
Additionally, if your website requires storing information about the user behavior / user activity, you may need to additionally check if the user logged in via FB already exists in your database. If not present, you can store the user's facebook id or something to uniquely identify the user later. With this as the primary key / user id, you can store user activity (such as inserting a record in orders table if the user purchases a product).
This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.
I've been looking into OAuth for a while, but haven't implemented it in any of my applications yet. I'm having trouble really understanding the full concept, so I still have a few questions that I haven't found an answer to, so I hope that anyone can help me.
I want a user to be able to start my application (WP8), login to facebook / twitter / microsoft / ... .
When he gets authenticated, I want to actually save this user to my own DB so I can add some user specific stuff like preferences, posts, ... .
What do I need to save in my own DB to specify a user?
Do I need to save the token itself or is this something that will be invalidated after a while? Or do I need to specify the user's name? With other words: What can I use as a unique identifier?
And what happens when a user would authenticate with for example facebook and he deletes his account?
And one more question, would you ever allow a user to connect to an application with 2 different service providers? If so, how would you make the coupling of these 2 providers to 1 user in your own DB?
I hope my questions are clear enough!
If not, don't hesitate to ask for more information!
Kind regards,
Gert
I assume that you have your own back-end where you authenticate your own users and your WP8 application is just a client.
First, let me distinguish between a user credential and a user profile. User credential is something that validates who the user is, e.g. username/password, facebook user id supplied with a valid auth token. User profile, is what you store in your own database about the user.
You also need to distinguish between a token you use to authenticate the user and the AccessToken Facebook needs to grant you access to user's data.
So... to answer your questions:
What do I need to save in my own DB to specify a user?
Create a record with user data (like preferences, and your unique user ID), and user's login method (e.g. Facebook) and credential (e.g. Facebook's user ID). This is your user's profile.
Do I need to save the token itself or is this something that will be invalidated after a while?
You can also store the Facebook AccessToken here if you've been granted "offline access" privileges by Facebook, but that is used for Facebook's access by you... not by the user's access to your app/back-end. For user's access you could just use a mechanism similar to cookie-based authentication - it's up to you. You could use the AccessToken as a kind of a "cookie", but you would need to always check against Facebook that it's valid.
With other words: What can I use as a unique identifier?
You could treat Facebook's ID as unique (so long as you never allow another account in your user profile DB to link with the same Facebook account)
And what happens when a user would authenticate with for example facebook and he deletes his account?
It's a good idea to have users still create a username/password combination that works with you site and only rely on Facebook login for convenience. In any case, Facebook provides a "Deauthorize Callback URL" when you create an app profile on Facebook. This is called when a user deactivates your app or deletes an account with Facebook. When you receive this call, you could send your user an email when an auth link to setup a different credential so as to not lose access.
would you ever allow a user to connect to an application with 2 different service providers? If so, how would you make the coupling of these 2 providers to 1 user in your own DB?
Sure, you could do that. Say you'd want to allow a Twitter account as well. You'd need to add a Twitter user ID field to your user profile database.
Here's another tip: create an ASP.NET MVC4 project in Visual Studio - the template includes an example of how to set up a user profile database with OAuth login.
Hope it gives you the high-level overview to investigate further.