When using Sign in with Apple there's an ASPasswordCredential option which will pull the password from the iCloud keychain. I can't find details though on "where" in the keychain you store things. i.e. how do I know what keys to store the user or password details under.
It seems to be connected with Password Auto Fill, which is available since iOS 12 (see section Password-Based Login inside https://developer.apple.com/documentation/authenticationservices).
So if your app already has this functionality you could associate existing users with their new Apple ID accounts.
Related
When using the Apple provider with NextAuth.js on the web server and signing in on a native device app (written in Swift using ASAuthorizationAppleIDButton and ASAuthorizationAppleIDProvider) using Sign In With Apple, how do you add a new user and account to the NextAuth.js database tables?
Besides signing into the iOS app, the user also needs to be able to sign into a website with Sign In With Apple and link his user account to other OAuth providers like Google (e.g. if signing in on Android). This question focuses on just Sign In With Apple on an iOS device and how to record that account info so that it plays nicely with sign-ins on other platforms.
Does NextAuth.js have a REST API that the iOS device can call to do this? Otherwise, if custom code on the Next.js server is needed to add the rows manually, is there documentation on what goes into each of the columns in NextAuth.js user and account tables?
if you just setup the AppleProvider, NextAuth.js won't keep a database of your users.
It lets Apple handle that and then just gets a signed message back saying, im paraphrasing, "Yup, thats Edward, and here are some more details about him.." and includes some basic info like your email address, profile picture URL, etc.
This is the basics of their OAuth-only strategy.
If you'd like to persist user data yourself and maybe add additional fields to the ones Apple returns to you, you'll have to setup an adapter. An adapter in NextAuth.js world is just a database where it will automatically save any new users and check against for existing users.
You can see the details of the various available adapters, including the default model/schema here: https://next-auth.js.org/adapters/models
I was interested in adding the Touch ID option into my app. I have found many SO posts and other articles on how to implement it and how to handle errors. My question is if the user logs in, and then goes to the preferences VC and (if the device supports it) enables Touch ID....how do I retrieve the users email and password from Firebase...or store it?
I could be wrong, but I can't imagine Firebase would allow me to pull the user's password. So, would I just store the password from the log in VC in a constant and pass it from VC to VC just in case the user wants to enable Touch ID?
That doesn't seem like a great option either..
Edit
I want to clarify my question.
Initially in my app a user logs into the app using Firebase using an email and password. Later on if the user wants to he/she can enable Touch ID so instead of typing johnSmith#email.com and abc123 it knows on this phone that the user is johnSmith#email.com and the password is abc123.
My question is: How to I retrieve that users email and password? I do NOT have a child in my database with a list of emails and I DO NOT have a list of passwords.
The only thing I can think of to get the user is the following
let user = FIRAuth.auth()?.currentUser
But is that enough for a Touch ID log in? That is just a random string and not his/her email
And how do I get the password?
As long as Firebase doesnt support TouchId you will have to manage the username and password combination yourself. You will have to ask the user once for the username and password when he/she enables Touch Id and store the username/pw yourself.
The way to store sensitive information is by using Keychain, here is a sample project from Apple on how to do that.
Next time the user login gets confirmed by Touch Id you pull the username/pw from keychain and authenticate the user.
my goal is to give my customers an option to lock their App's Data, so when they give their iPad/iPhone to someone else for an extended period of time, users can't access or accidentally look at confidential data.
[Some Background: It's a medical Application where physicians/staff-members would give iPads to patients. Now the patients are supposed to access some contents, yet shouldn't be able to look at other patients data]
So far, I have a password inside my App. But when a staff-member forgets and wants to reset it, the only thing I can do is "deletion of the whole database". I have a Disclaimer telling people to store their password somewhere, but this is still not the optimal user experience.
Is there anyway I could authenticate the user via his Apple-Password? This way only the person knowing the Devices-Account password can access the data and can always reset the Apple-Password with Apple.
PS: Server-Solutions, like having a User-Password pair with reset-via-mail on a server of mine is out of the question, since it would add to much complexity for the users and in many medical situations the Device shouldn't have access to the web.
Multiple thoughts:
I am not aware of any native public API to authentication using Apple password.
If your app is enterprise app, possibly you can use native private API. I would recommend to disassemble AppStore and check how does it do authentication then
You can also to try to access to some Apple web page which requires authentication and pass to it apple account and password and see what it will return. If it authenticated correctly, then you are fine and you can reset a password.
To make it secure, you will need to ask a user to enter it for a first time, so you can encrypt your encryption keys using authentication material (so you can decrypt encryption key later on).
However, I am not very big fan of this solution, since you can change Apple password and you will be stuck in such case.
Server solution is the best option and it's not that complex. Another option is Forgot password. You ask something what administrator know ("What is your first pet?") and he enters the answer when your application is configured and this answer could be used later to unlock your app.
P.S. And the best solution at the end (which is absolutely shameless self advertisement). A startup which I am part of (SpydrSafe) works on the product which solves exactly your problem. In fact, healthcare is one of the verticals which whom we actively works. If you are interested, contact me (my email is in profile)
if you authenticate the user via apple password, and they forget their apple password, then in order for them to retrieve that password is by reset-via-email .... so either way you are stuck with that dilemma.
As for actually using your apple password, no.
Best way to get what you want is to have the password stored somewhere in real life. Like another computer that the doctors can report to and ask for passwords or just don't forget the password.
My app is a sync solution (imagine dropbox).
The user needs to sign in to access the app's features, and if he does not have any account already created, he can sign up.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
but Apple has rejected this app saying:
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
We found that your app requires customers to register with personal information to access non-account-based features, which is not in compliance with the App Store Review Guidelines.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. Additionally, the requested information must be relevant to the features.
Although guideline 11.6 of the App Store Review Guidelines requires an application to make subscription content available to all the iOS devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be made optional.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Please help me solve this. Many apps like dropbox/facebook require login.
I don't get the exact reason why they rejected my app.
Also, please guide about the in app purchase, why registering cannot be mandatory
Asked App Store Review people for clarification on their rejection.
They accepted it. and the app got approved :D
Its on Appstore now :)
I also Faced this kind of Problem and my app also Rejected due to this.And Again I Changed my App flow Like User Registration will be Optional. User can See all the Feature of the app with out Registration by skipping this step.If he want to do something user-specific then you can ask to register such as : (user like,comment,photo upload etc) or else he can use the contents and features which are public.
in Case of in-app Purchase You can Prompt user that if He will Register with your app he can able to use this Content in his all devices.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Apple does not allow apps that require you to share person information to work, like an e-mail address.
You options are, remove the need for an e-mail address or remove account creation form you app and move it to a website.
It also states that you app is asking to create an account to access the full app and even needs the account or acces features that do not require the user to have an account. You can make those features available with out the account creating you might be able to get thru the review.
The reason apps like Facebook and Dropbox got thru the review proces is because they don't have a register option which is in app only. They redirect to a website.
I recently spoke to an Apple Rep over the phone in regards to an app of mine that was also accused of violating clause 17.2.
I explained to him that the email would be used for password recovery, monitoring transactions within the marketplace, and managing any inappropriate behavior (such as users uploading offensive or copyrighted content). The rep responded, "Sir, the clause states 'Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected'. I cannot allow you to require your users to submit their emails if its not account-based". He did not seem to understand that the emails are account-based for the very sole purpose of security.
I did mention to him that Instagram and Facebook alike require logins at startup. He simply replied, "Yes but those apps are entirely account-based."
Honestly, I felt he was blindly following Apple's Guidelines ("Because that's what it says we must strictly follow!"). He had little understanding of how social networking apps operate, and even less understanding of the law (specifically the DMCA - on a separate issue). Explaining to them how all that works proves to be futile; they wont budge because they are asked to follow Apple's BROAD Clauses as strictly as they do.
My conclusion: I had to compromise the app's user flow such that the app's registration page can be skipped, and all other functions within its marketplace were locked to non-registered users. It makes no sense.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user.
It seems to me that the point is that you are asking the user to provide his email address as a step towards the creation of a user account. This is different from what dropbox and other apps do (i.e, you provide your credentials for your dropbox account, which is different from your email address, although it can be the same).
You may either remove altogether email verification, or you could postpone it to a later point when you have made clear to the user that this is required to access private information.
I got the same thing last week and this is Apple's reply:
As for the 17.2 issue, a nickname, avatar, or sharing are not inherent or specific features of those social networks, and thus, the user should not be required to register with those services, or provide you with access to their social network accounts. The user should not be prevented from using your app and service if they do not provide this information.
Instead, it would be appropriate use your own authentication method and give users the option to create a nickname and upload an avatar, independent from those networks.
Moreover, we realize that these social networks may be very popular. However, the popularity of the social network is not an appropriate reason to force a user who has not, or chose not to register and provide their personal information to those services, before they can use your app.
Therefore, we ask that you to include your own authentication mechanism to allow the user the option to register only with you, creating an account with only the information needed and relevant to your app's features.
Best regards,
App Store Review
So in short, you have to provide custom authentication and not just use Facebook. Although I've seen many Apps who do require you to login with Facebook.
Thanks,
James
It happened same for me, although the first version was approved, the second version was rejected for this reason, I added the Skip button at the landing view.
It's all summarized in the last paragraph. Apparently, your application doesn't inform the user (in a clear way) that registering is for syncing and from their reply, it seems that your application is useless without the Sign Up.
If that's the case, you should be more specific why you need the user to register.
On a side note, I personally don't like the applications/websites that force you to register before you see or try anything. I hope your application isn't the same.
My iPhone App connects to a web service using a username and a password.
I prefer to save the credentials in the Application Preferences (settings bundle) like the Mail App. Is this secure enough? Is it possible to save those values to the keychain (via Application Preferences)?
Edit:
I want my users to enter their credentials in the Application Preferences of my App. Normally, I can retrieve this data in my app with NSUserDefaults. But Application Preferences saves the data as plain text and it's neither encrypted nor hashed. Is there a safe way? Eg. I know the keychain on the iPhone and I find it great! Can I use the keychain to hold the credentials entered in Application Preferences?
Food for thought: How does Apple do it? I mean, when I want to use the Mail App, I provide my username and password in the Application Preferences. Are those values stored as plaintext?
Did you check the keychain documentation? On the security, see this white paper by the Fraunhofer SIT institute.
Keychain Services will be required for secure storage. Using NSUserDefaults will not secure your data.
You can save it securely using Security.framework.
It is very nice sample from Apple where many aspects of using that framework are discussed. I advice you to look through it. Here is the link to that sample: GenericKeychain
This sample shows how to add, query for, remove, and update a keychain item of generic class type. Also demonstrates the use of shared keychain items. All classes exhibit very similar behavior so the included examples will scale to the other classes of Keychain Item: Internet Password, Certificate, Key, and Identity.
It seems that many people do not seem to understand your question. Unfortunately I can not find the answer myself. The question is how do you use the keychain AND NSUserDefaults at the same time.
I too would like to use the NSUserDefaults interface.
Hopefully we can figure this out...
One option would be to store just the username. Then when the app starts if there is no password in the keychain or if there is a wrong password in the keychain--ask for a new password.
You can remove items from NSUserDefaults when your app runs after the user uses Settings to enter them into the app's Application Preferences. Then put them into the keychain. But these items may be in plain text in storage in the interim(depending on which iPhone model, some may encrypt the flash storage and the backups), before you can remove them from NSUserDefaults.
Apple owns the entire OS and of course the Mail app. They are using features outside of the public SDK, because they can. How do you think the Mail app can run in the background and keep checking for your mails? Normal app can't achieve this :(
Back to your main question, using keychain is the right way to go. But you probably have to disallow users to enter username & password in Application Preferences. There is no way to secure that.