I was reviewing iOS documentation on accessing keychain items with Face ID or Touch ID and it got me thinking:
Can we authenticate users based on biometrics into an app that requires a username and password WITHOUT having those credentials saved to keychain?
My first reasoning is no because you still need those credentials to validate the user, but could a passkey circumvent this?
Thanks in advance!
I’ve read documentation but I’m unable to deduce this for sure.
I lost the p12 key file that was generated when setting up Sign In With Apple and need it to setup an auth service. The app using this service is in production and I am concerned that revoking the key and generating a new one will cause the account info (user id's & relay emails) to be different than they are now.
Do anyone have any insight on this?
I can't find a stack where I can ask this question however it's related to servers, and storage.
I know how game admins can simply unban an account.
I also know how when you get your account banned, it doesn't get deleted (which would help the servers) But I also don't understand the concept of getting your account banned.
I understand that you can't access your account anymore however its still there.
So the account itself, is it reduced in memory or is it just a message saying your account is banned?
All the information is saved in a database. The idea is soft deletion. The table will contain a column that says if it's banned or not. Then, when the server and client are authenticating with each other, if the client attempts to access things without permission, the server will reject it. The data associated with the account isn't deleted, it's just unusable since the server will reject auth credentials.
At the first time, while signup with Gmail and password, firebase saved the credentials correctly. But the next time, I Login with Firebase Google authentication with the same Gmail which i gave while signup, the credentials are overriding in firebase account. After overriding the credentials, we are not able to login using that signup credentials. Can anyone explain how to achieve this?
What happened
In the first screenshot you signed in with the email+password provider of Firebase. While this is a valid sign-in method, it means that anyone could've entered that email address, even if they don't actually have access to the Google account for that gmail address.
There is no security risk here, but the level of trust we can put in the value of email address is low. For this reason the emailVerified property of the account is marked as false and you'll typically want to require that the user verify their email address before allowing them to continue.
In the second screenshot, the user signed in with the same email address, but now with the google.com provider of Firebase. This means that Google now verified already that the user has access to the underlying gmail address of the account. Since the google.com provider is the trusted provider for #gmail.com accounts, the system replaces the previous account.
Also see:
Authentication using Facebook at first and then Google causes an error in Firebase for Android
Firebase Overwrites Signin with Google Account
Trying to understand Firebase Authentication one account per email address and trusted providers
What you can do
You'll typically want to prevent multiple users from signing up with the same email address. For this, you'll want to configure Firebase to only allow a single account per email address in the console, and then use account linking so that the two (email+password and google.com) accounts in your scenario are merged.
Did you verify the email or phone number from the first login attempt? If not, this is by design:
After sign-in completion, any previous unverified mechanism of sign-in will be removed from the user and any existing sessions will be invalidated. For example, if someone previously created an unverified account with the same email and password, the user’s password will be removed to prevent the impersonator who claimed ownership and created that unverified account from signing in again with the unverified email and password.
Source
I just ran into this problem and here is a longer and more in depth description. (Things change often, this was true in Nov 2021.)
SHORT VERSION: As #Frank van Puffelen said, this is by design. The issue is that email+password is not a trusted provider usually, so a trusted provider like Google Authentication overwrites that method. It does this silently (I think, didn't check every field in GoogleSignInAuthentication object.)
It does auto-link after a password reset OR the email is verified via a link. See https://firebase.flutter.dev/docs/auth/usage/#verifying-a-users-email on code to do that.
Also: I don't recommend turning off One account per email address as some others suggests . See the reason for that at the end.
"Weird" Behavior under default One account per email address
In my app, the following happens.
SignUp via email+password for testUser1234#gmail.com.
creates an account for c_example_account#gmail.com with provider=Email/Password as indicated by the envelope/mail icon in the firebaseAuth dashboard.
LogOut and re-signin via Google Sign In for c_example_account#gmail.com
The provider is changed. Old provider is Email/Password icon (envelope). New provider is Google icon. (like the bottom three accounts in the screenshot). Note also that the User UID is the same. So anything anything linked to that User UID is still okay.
Since the Email/Password login method (AKA) provider was removed for c_example_account#gmail.com, the user can't login with that method anymore. IMPORTANTLY: This is done silently without the user getting any notification that the Email/Password login was removed.
Trying to sign on using Email/Password will result in an error Incorrect Password. Note: one might expect it to give an error like "Only Google Sign-In is available", but it doesn't. Contrast this to when the email doesn't exist (like trying garbage#123457.com), which has an error Email is not found...
Now, it gets a little weirder...
Suppose the user uses "Reset Password" like being called like this
Future<void> resetPassword(String email) async {
await _firebaseAuth.sendPasswordResetEmail(email: email);
}
Then, the firebaseAuth console has TWO methods for the same USER UID. See the second and third line in the screenshot.
Now, both methods are allowed. The difference is that the first time was a createUserWithEmailAndPassword() like
await _firebaseAuth.createUserWithEmailAndPassword(
email: email,
password: password,
);
...but this time it was created via a "Reset" event
Future<void> resetPassword(String email) async {
await _firebaseAuth.sendPasswordResetEmail(email: email);
}
... that gave a link via email sent by firebaseAuth service. In this case, the email was verified.
Recap: Now both methods work. The two methods being (1) Google authentication and (2) Email/Password. In Google parlance, the accounts have been linked: https://firebase.google.com/docs/auth/android/account-linking. Linking means One User UID, multiple login methods
Why the funky behavior when Email/Password is created in two different methods?
~~I couldn't find this documented in firebaseAuth, maybe because I didn't look hard enough or maybe because it's not a common issue. ~~
UPDATE: This behavior is documented in an issue comment from April 2020.
I think the reason is because the _firebaseAuth.createUserWithEmailAndPassword version has an unverified email. So, anyone can create an account for anyone else assuming that the email+password combination doesn't exist. For example, I could create an account with username president#whitehouse.gov without actually having access to that email. If the actual president logged in via Google Authentication, then I'd have bogus access to that user's info. Except that the clever google engineers decided that the verified Google Authentication then triggers the deletion of the unverified Email/Password provider/account instance.
In short, the logic might be: verified trumps/overrides unverified. See https://firebase.google.com/docs/auth/users#verified_email_addresses
Again, none of this is documented explicitly for Email/Password. But it is hinted at in the documentation, like if a Facebook Auth account gets over-written by a Google Auth.
Snapshot of the Verified Email details
Copied from: https://firebase.google.com/docs/auth/users#verified_email_addresses
Bolded added by me, for emphasis
In some situations, Firebase will automatically link accounts when a
user signs in with different providers using the same email address.
This can only happen when specific criteria are met, however. To
understand why, consider the following situation: a user signs in
using Google with a #gmail.com account and a malicious actor creates
an account using the same #gmail.com address, but signing in via
Facebook. If these two accounts were automatically linked, the
malicious actor would gain access to the user's account.
The following cases describe when we automatically link accounts and
when we throw an error requiring user or developer action:
User signs in with an untrusted provider, then signs in with another untrusted provider with the same email (for example, Facebook followed
by GitHub). This throws an error requiring account linking.
User signs in with a trusted provider, then signs in with untrusted provider with the same email (for example, Google followed by
Facebook). This throws an error requiring account linking.
User signs in with an untrusted provider, then signs in with a trusted provider with the same email (for example, Facebook followed
by Google). The trusted provider overwrites the untrusted provider.
If the user attempts to sign in again with Facebook, it will cause an
error requiring account linking.
User signs in with a trusted provider, then signs in with a different trusted provider with the same email (for example, Apple
followed by Google). Both providers will be linked without errors.
You can manually set an email as verified by using the Admin SDK, but
we recommend only doing this if you know the user really does own the
email.
Why not turn off One account per email address
By default, the setting One account per email address is active as #Deva wrote. But, unchecking this means that there are two different accounts (User UIDs) for the same email. One via Email/Password and one via Google Authentication. They will have separate User UIDs in Firebase Auth, so that may confuse you. Furthermore, if you manually link in your app two User UIDs, this creates a security hole: Someone can create an account without email verification to get access to an existing account. So don't do that.
Related StackOverflow questions and links
https://stackoverflow.com/a/60276351/233382
why i can't link email/password to the same email exist in google sign in provider in firebase flutter?
https://github.com/firebase/firebase-ios-sdk/issues/5344#issuecomment-618518918
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.