I'm creating an iOS app that uses CloudKit and I want my users to log in to the application. Ideally they will just need a username and password. If the password is forgotten they'll need a way to reset it so I'll have to store their email as well.
My question is, What is the best practice for user account information, i.e. username, email, and password?
Is it as simple as storing the username publicly, then the email and password privately on the CloudKit user?
The nice thing about working with CloudKit on iOS is that authentication is built in. You don't have to worry about usernames and passwords.
When a user connects to your iCloud container via your app, they will only have access to what is stored in their own private database. They can also see what you give them access to in the public database.
If you can elaborate a bit more of what you are try to do, I can try and give some more guidance. But in short, you don't need to worry about authentication.
Related
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 want to offer some paid content in the app but I don't want the user to go through an Authentication process. I would like him to enter the app and directly be able to buy some of the content and remember that this user has bought it if he comes back later or uninstall/reinstall the app later on. (Like most meditation app on the Store right now)
Is it possible using Firebase Services and if so, what would be the good way to track paid content for anonymous user?
An Anonymous user IS a user without details (Name, email, password, etc). It has a unique UserID
So YES. You can save anything to the database using the User's unique ID. But remember. Every app is capable of performing operations inside their sandbox directory. which also has a unique ID and resets when the app is uninstalled.
In a sentece. Firebase won't remember the Anonymous user ID if the app was deleted intentionally.
The docs does state this very well:
You can use Firebase Authentication to create and use temporary
anonymous accounts to authenticate with Firebase. These temporary
anonymous accounts can be used to allow users who haven't yet signed
up to your app to work with data protected by security rules. If an
anonymous user decides to sign up to your app, you can link their
sign-in credentials to the anonymous account so that they can continue
to work with their protected data in future sessions.
Read more:
Authenticate with Firebase Anonymously on iOS
You could theoretically set it up to where it would redirect the user to a TextField page asking him/her to make a "password" and "PIN" of sorts. This "password" and "PIN" could then be stored into a SQL server database as an anonymous user. When re-downloading the app you could have a page dedicated to purchase recovery where all a user would need to do is input this "password" and "PIN", after they have correctly entered both it would return purchases to their account.
things to be wary of:
-People may use the same password, which is why I recommended a PIN as a way of two-step authentication. Keep in mind also that your app will need to test the password against the server before uploading to make sure that the password doesn't already exist and tells the user that the password cannot be used in such case.
-This is essentially the same thing as an account with a username and password... the only difference is that you aren't going to be collecting other information on them, such as email and birthday, etc., making it more anonymous.
-This is a very rare case of question and I know this is a crappy answer, but honestly this isn't the best idea to implement unless your app heavily relies on it.
I am creating a basic iOS app using objective c where the user needs to register and I am saving the login credentials(username, password and email) in keychain.
I want to give forgot password functionality and was thinking that once the user clicks on forgotten password, I will ask for the user email and match with stored one in keychain and if positive I will send email from the app in background to the user email with password in it.
However I am not sure is this safe and good practice?
I am not using server, so cannot send mail from server.
Or is there any better way to do it. Please suggest?
I am creating an application using Appcelerator wherein the user needs to enter the username and password to login. Once logged in, the user can enable TouchID for authentication. After logging out, the user can use the TouchID for authentication and use the application.
My flow is that once the username and password is provided, I store those two information in Keychain using the following module iOS Keychain Module. Then I use ti.touchid to authenticate the fingerprint, if success, then I retrieve the username and password from keychain and then send it over HTTPS web service call and login the user to the application.
My query is that, whether this is an acceptable approach.
I am not an iOS developer nor does any ti or keychain terms mean anything to me at all. That's for a start and to reduce the number of down votes i might get.
In terns of security, I would suggest that you imagine obtaining that particular user's phone where you know you have some authentication credentials stored. Let's say I am a user of your app, already logged-in and have my credentials saved somewhere on my device, and you obtain this phone by stealing it from me.
Now, will you be able to access my account in anyway? Will a hacker with access to the physical phone be able to retrieve any information stored in your Keychain storage?
If so, If you can think of anyway to do so, then your approach is not valid.
I understand you want to save users sometime by making sure they can login with just their fingerprint, which is a valid reason to think of such an approach, but you will have to think everything in terms of reverse engineering.
Additional recommendations would be using an on-the-fly hash to store information in the Keychain and making sure to check that before restoring the same. For example, user credentials saved on "home wifi" can be verified with your fingerprint only "at home" on the same wifi network where the same will be invalid on a different network.
i.e)
(keychainItem.x = y) is TRUE ONLY IF (something else)
where this (something else) is something that will prevent hackers from accessing the Keychain even if they have access to the device itself.
I do this myself when programming web applications with stored cookies. I for example use a stored cookie ONLY IF it is being accessed from the same IP it was saved from. Anytime that IP address changes, user will have to re-authenticate even if the cookie values are correct.
Hope this helps.
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.