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.
Related
I'm writing an offline application that uses the Dropbox API. When a user comes to the application, I'm using the https://api.dropbox.com/oauth2/token (docs) to get a refresh_token, which I store for later use.
I am calling the same endpoint every time the user logs in (unless I've already got the user's data in a cookie). I'm not sure that this is the best way to go about it: I at least need to get the user's account_id, so that I can look up their refresh_token in the database if I already have it. But every time I call https://api.dropbox.com/oauth2/token, the user is redirected to the Dropbox app authorization interface, as if they've never approved the app before.
So I would either like to know how to stop Dropbox from forcing the user to re-authorize an app every time. Or, if that is just how https://api.dropbox.com/oauth2/token is supposed to work, I'd instead like to be able to get their account_id somehow when they visit my page.
(In case it's relevant, the app is still in development mode at this point.)
The https://api.dropbox.com/oauth2/token endpoint is an OAuth endpoint that the app can call to get an access token/refresh token. Being an API endpoint, it does not itself redirect the user to the Dropbox app authorization page.
The Dropbox app authorization page is at https://www.dropbox.com/oauth2/authorize (documented here), and the app decides if/when to direct the user there to authorize the app.
You generally only need to send the user through the app authorization flow (sending them to https://www.dropbox.com/oauth2/authorize and then calling https://api.dropbox.com/oauth2/token) once per user for an "offline" application. Once you do so, you should store the resulting refresh token for that user. You'll typically store the refresh token for that user tied to their user account in your own app.
Exactly how you manage the user accounts in your own app will depend on how it's built, but, as it sounds like this is a web app, typically you would use the user's browser cookies to identify the user when they return to your page so that you can look them up in your database and retrieve their details, such as their corresponding refresh token. (Or, if they're not already signed in to your web app, you would have them do so first.)
Greg's answer is very helpful, and very politely addresses my misunderstanding of the auth flow. (I was revisiting old code I'd written years previously—obviously I should have documented it better than I had!)
In the end I believe that Dropbox was forcing me to reauthorize because my application was in development mode, and had a small user base. When I used the identical code in an app set to production mode, it stopped forcing me to reauthorize. So the “problem” is really a Dropbox security feature, and the solution was just to use production mode.
A new iOS app should be able to connect to a web service to sync data across devices.
I like the way the diary app Day One solved this:
On registration the user can choose to use mail address to setup a "real" account or to sign in with his Apple ID
When using the "real" account the mail address has to confirmed and a username and password has to be chosen
When using the Apple ID Sign In no additional steps are needed. The app is connected to the web services using some random user ID
When being installed on a new devices it is no problem to re-connect using the Apple-ID method.
Problem 1: How to access the Apple ID?
As far as I know it is not possible for the app to really to access the Apple-ID. Or is there some undocumented way to do this? How is this possible?
I suspect that the app instead might use iCloud to store some token? The iCloud storage is linked to the Apple-ID, thus when installing on a new devices it would be possible to recover the token from iCloud and use it to reconnect.
Or are there other / better methods?
Problem 2: How to handle the authentication?
Let's set Problem 1 aside and assume that we have solved the problem of creating some cross-device username. How could be handle the authentication?
Solution 1: Only the token (Apple ID / iCloud stored username / etc.) is used for authentication. If a request from the app to the server contains a valid username token access is granted.
Solution 2: In addition to the username token a random password is generated when creating the anonymous account. This could be done on the device or on the server. But since the password has to be known on both ends, it need to be transferred from one end to the other at some point.
2a: Trust in the HTTPS connection and transfer the plain password
2b: Use some other method (e.g. Diffie-Hellman) to agree on a common password
On first sight 2b seems to be the most secure solution but is the really the case? The sync data is not encrypted but "only" trusts in the HTTPS connection. Would it add extra security to transfer the password using another method?
Additionally, does it add extra security to use a "password" at all? This is not a password the user selects for his user selected username but a automatically generated password for a automatically generated username / token.
Would it not be the same to just use the generated username token? Only who has access to the token / Apple ID / iCloud account, etc. can access the web service.
So, which solution is the best? Am I missing something and there are better solutions?
As of iOS 12, Apple provide a SDK for developer to access user Apple ID - with user's consent, obviously. Developer can use AuthenticationService SDK to achieve this. Please read more at the documentation. I'm sure this is how Day One app does what you describe.
I'm creating a book library app, where people buy an account and become able to read all the books...
In the past, we were able to get the UDID of the iOS device and the login only works from this specific UDID.. now apple prevents this, another solutions were there like OPEN-UDID but now doesn't work...
Are there any other means to prevent the user from giving the credentials to another people??
The only solution on top of my head now is this :-
When a user login, a flag on the server becomes true, and when another account try to login using the same credentials, it will show an error message "you are already logged in on another device".. when the original user logs out, the flag becomes false.. this will prevent the account from being used on multiple devices at the same time.. but the drawback is, what if the user unInstalls the app without logging out?
Is there a research on this topic that covers all these scenarios?
Is there a way to use apple keychain or iCloud or any other solution ?
What you can do is on new login invalidate api request(and send them to login screen) of previous login you can use device token with each api to check if you want to send data to device or it's a old login token and needs redirect to login. you have to just store a device token for each account login if it matches then send data else redirect to login
Edit 1:
if you uninstall the app then you have to login again from other device to access the books(data) and in each login you'll replace the old token with new one. Now only device which has this new token can access books. All other device if there are any login left in any device then they will get message from API that token not matched and you have to redirect them to login page again
I am creating an app that allows the user to log out of the app and log in as different user if they want to. Is there any way to obtain a new device token from Apple once the new user logs in? Is there a way to force call the didRegisterForRemoteNotificationsWithDeviceToken method?
No, you can't request a new device token. They expire from time to time, and only then will you get a new one (or if you have a different app with a different bundle id, the token will be different).
Create a function to handle didRegister and call that from didRegisterForRemoteNotificationsWithDeviceToken. Then use that function when you need to force the call.
Since users are logging in, pass the information with the device token to the server every time someone logs in and associate the user to the token on the server side.
There is no way to get a different device token. You need to remove the token from the backend when the user logs out.
I'm not sure how it behaves in iOS7 and later, but prior to iOS7, all applications on the same device would get the same device token, and therefore what you ask is impossible. As of iOS7, each application gets its own device token, but I'm not sure if that token can change on consecutive registrations.
You can always force call the didRegisterForRemoteNotificationsWithDeviceToken by calling registerForRemoteNotificationTypes, but usually you'll get the same device token.
If the goal is to associate notifications with specific users, then as of iOS 10, you can try implementing a NotificationService extension to filter only those notifications associated with the currently authenticated user. While multiple users on the same device will be associated with the same device token at the server, the client will only display notifications for the current user - assuming that only one user at a time can be logged-in.
This approach also allows for having notifications that don't require authentication - just pass those through unaltered.
As mentioned above, you can force a request-response token update after user login by explicitly calling UIApplication.shared.registerForRemoteNotification (Swift 3+). Then send that user+device token combination to your application server for use.
If I want to make sure that the ios app has access to user's facebook account, which method should I follow? I have seen checking for FBSession.accessToken in some places and FBSession.activeSession.isOpen being checked at some other places. What is the difference between these two?
Thanks.
If you want to communicate with Facebook via your app and considering that you have setup the project correctly i.e. the FacebookAppID etc, you call for an active session via
- (BOOL)openSessionWithAllowLoginUI:(BOOL)allowLoginUI
method. The access token stores the information that an app has been permitted with certain permissions your app asks and you check for a valid access token each time so that you don't have to validate the app each time.
FBSession.activeSession.isOpen is used to check if there is an active session in open state and if so, you can move forward with whatever your app intends to do with Facebook.
FBSession.accessToken tells you that the app has access to the user's Facebook account, whereas FBSession.activeSession.isOpen tells you weather the current session is open or not. We prefer to use FBSession.accessToken to check if the app has access to the user's facebook or not.