Is there a way to make firebase authentication consider the following email addresses as equal for the purpose of signing up or logging in a (new) user?
imauser#gmail.com
imauser+test#gmail.com
im.a.user#gmail.com
im.a.user+test#gmail.com
Firebase Authentication intentionally does not normalize the +suffix our of the email address, as this is used in certain regions to allow multiple users to share a single account.
This behavior is not configurable, so if you want to map these accounts, you will have to filter it in your application code before calling the Firebase API to sign the user up or in.
Related
Currently I am working on feature login with phone number, user will enter their phone number and server will send sms which contain OTP.
I have researched many days for the solution to integrate with Keycloak but still stuck on it. I saw that we need to use authenticator SPI, extend keycloak and implement code which we want.
I also have thought about using other third party to handle sms and otp stuff ( like Firebase) and then will use firebase token to exchange keycloak token but firebase is not supported provider in Keycloak therefore can't do this flow
I just want to ask is there any other ways to do this feature without extend Keycloak? or simply can we get keycloak token via API but without password
I can imagine small solutions around keycloak, which together can get what you want. Will try to explain :)
Imagine phone number is user login in keycloak.
Imagine password is system generated, like encoded phone number + salt; basically hash algorithm know what the password is, user don't.
You use third party library, which verify user mobile number and text message user enters, and it works.
You create system-user in keycloak, keep password encoded in application.properties, assign him some admin roles like create user, query user, something else you need to manage users.
And now, workflow is:
User enter mobile number 123, sms getting send
User verify sms,
you know user number 123, you generate password
hash1(hash2(123+salt)) (see point 2)
Using system-user you login to keycloak, get accessToken for system-user
using accessToken check if user exist, if not, create user 123 with password hash(..), assign default roles, groups
logout from system-user
login with user 123 and password hash(..), load user accessToken, build User Profile, put in to SecurityContextHolder.getContext()
If you make all small bits working, should work all together.
or just ignore me if I am wrong! Good luck !
I'm using ASW Cognito for authenticating users. Cognito has a well-documented flow to handle users who have forgotten their passwords.
How do I handle users who have forgotten their usernames? Is there a built-in flow that lets the user enter their email or phone number, and then receive an email or text with their associated username? I found the ListUser API, which returns all the users in a userpool. I could write a Lambda function that filters through all my users, looking for a match on email or phone number. But this seems like overkill.
Unfortunately, there is no default out of the box workflow of "Forgot Username".
I am implementing similar workflow. We ask user for their registered phone number/email, and we retrieve username based on that number and send it to email/phone according to configuration. If user is configured to use email and phone both, we send SMS to phone if user forget username (which is email id they used during sign up).
One major drawback of this approach is that, we need to provide ListUsers API call access to anonymous user which is a potential security issue but can't seem to find any other way by which we inform user about their login details.
For those, who are looking for the solution, don't give the anonymous user access to ListUser API as suggested in the accepted answer.
There are two ways to implement 'Forgot username flow'.
Enable email as an alias for your Cognito User Pool:
Calling this API causes a message to be sent to the end user with a
confirmation code that is required to change the user's password. For
the Username parameter, you can use the username or user alias. The
method used to send the confirmation code is sent according to the
specified AccountRecoverySetting.
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ForgotPassword.html
The user will be able to reset the password with their email and code delivered to provided email address. If you still want to remind the username, you can use Lambda trigger to generate the password reset email with both username and verification code.
Use the backend (web server or lambda) which will receive the email address as an input to the 'Forgot username flow'. The backend will have permissions to invoke List Users API (https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_ListUsers.html) and will perform user lookup using the email. You now can go into Forgot Password flow using the retrieved username. Lambda trigger will be used to generate password reset email with username and verification code.
You can protect this API from abuse using WAF and/or captcha.
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
I'm currently using Google authentication provided by Firebase, but I need to generate a unique id for each client connected to Firebase, i.e. even if user is logged in with the same Google account on 2 different devices, I'd like to have a different id in auth object.
I want to do WebRTC signaling over Firebase and I need to be able to uniquely identify a device (even if a user is logged in with the same account on all of them). I also would like to have this id in auth object, so that I can use it in security rules to define that e.g. only given device can read messages sent to it.
Is it possible to do it without custom authentication and generating JWT token on the server? I'd like to add more providers in the future, so I'd really like to avoid handling it myself.
Not without custom auth. – Frank van Puffelen
I'm using Firebase for an Atlassian Connect AddOn. I want to use Firebase users to secure the data.
The users will be identified by a clientKey provided by Atlassian (probably after I fudge it a bit) - NOT BY EMAIL.
Ideally, I don't want to have to do my own authentication here, as the Firebase.createUser method would suffice entirely if I could provide something other than an email to it, but I can't find anything like that in the documentation.
Is there a way I can create Firebase users WITHOUT AN EMAIL (just an ID and password), without going to all the way into oAuth and all that jargon to create my own custom authentication?
A Firebase user must have an email. If that is a problem then we can't use a Firebase "user", but instead a "token" (which must have a UID as part of it's payload and hence behaves the same way in terms of security once it reaches their datastore).
If you don't need a password, then "instead of double-authenticating and duct taping" as #Kato kindly pointed out, you can generate your own Firebase tokens and serve them to the client.
If you require the user to provide a password then you'd have to implement your own verification before you generate the token and serve it to the client. Since there's no Firebase user involved anymore, but rather a token your privileged server can arbitrarily create and serve, it's your responsibility to ensure you're doing that at the right time (i.e. when a user has provided your server with an adequate ID and password).
Read more about Custom Authentication here and tokens.