I want to maintain an account disabled until it passes the email verification.
Problem is, as a user registers itself via createUserWithEmailAndPassword, the newly created account is ready to be used.
The only way I can avoid authentication is to check email verification flag via js in client app and deny login, but I don't want to rely on client controls, I'd prefer that firebase itselfs deny the authentication until email is verified.
Is there a way to accomplish this?
You can (and should) also check if the email is verified in the back-end, either:
in security rules, if you're using Firestore, Realtime Database, or Storage
in your own backend code, using a Firebase Admin SDK
When you do this, the client-side check is nothing more than a way to show the correct UI for the current state ("hey there, your email isn't verified yet. Check your inbox, or click here to resend the email"). It's the server-side check that controls access to the data, which is precisely how you want it to be.
This has been covered quite regularly before, so also see:
the Firebase documentation on implementing role-based access control on Firestore
How do I lock down Firebase Database to any user from a specific (email) domain? (for Realtime Database)
Only let pre-verified users log into Firebase
Related
I want to provide my application's users the ability to add a second factor of Authentication and I'm currently using Firebase for logging and signing in new users. Firebase already lets you use a second factor but your only possibility is to send an SMS to a verified phone number. I want to replace this second factor with Authy OneTouch so I was wondering what's the best practice in this case.
Right now here's how I authenticate my users:
An user logs in using a form in my client. Under the hood I'm using signInWithEmailAndPassword, retrieving the IDToken from Firebase and setting persistence to NONE.
The client sends a post request to my backend attaching the IdToken and singOut immediately after.
If the token is valid, the server will provide an HttpOnly session cookie storing that token that will be sent along with future requests to my backend to keep track of the user's authentication state.
How I plan to change my workflow:
Through the profile page, the user may or may not opt-in for the second auth factor.
On user opting in I'll send a request to my server and it will call setCustomUserClaims to attach a custom mfa claim and do the necessary steps to register a new user on Authy.
On logging in I access the claim calling getIdTokenResult and access tokenResult.claims.mfa. If it doesn't exist then the process goes as the previous list. Otherwise I log the user out, ask him/her to go through the second factor, and regularly poll a specific URL that Authy provides to get updates on the status of the second factor challenge.
When I detect that the second factor challenge was successfully completed I send a post request to my backend attaching the idToken I got from Firebase and relevant infos I got from Authy's response.
The backend verifies if the idToken is valid (to make sure the email-password challenge was previously performed), then proceeds to generate a custom token with Firebase user's uuid, email, password, mfa-status using createCustomToken, then performs a signInWithCustomToken and sets a session cookie in the response.
Is my idea fundamentally correct? In case does Firebase provide a way to customize its default second factor and I just missed it? Thanks.
While Firebase Authentications's paid brethren Google Cloud Identity Platform does offer 2FA with SMS, neither of them currently provides an option to use/require a custom second factor for authenticating a user.
It's a common request though, so I recommend filing a feature request for it.
Until the feature is added to Firebase itself, the only way you can do something like that is through a custom provider, which allows you (but also requires you) to take control of the auth flow yourself.
Context
I'm using Firebase phone authentication. and i have one mobile app for users and one web app for admin.
both users are stored in one collection.
Requirement
Now I want to validate that user is a admin when a user try to login in Web Application.
I keep data with users that "isAdmin" like this...
users:[
{
name:'John Doe',
phoneNumber:'+911234567890',
isAdmin:true
} ]
Now I want to validate every web authentication that user is an admin. otherwise i want deny the authentication,
Language: Javascript
Since the user's role is stored in a user document in a Firestore collection (named users if I correctly understand), when the user is signed-in (and therefore you have the user's uid and phone number) you should query the users Firestore collection to get his/her role (isAdmin true or false).
Then based on the role, you can either display the content of the Admin app or show an error and sign-out the user (you cannot "deny the authentication" but you can sign-out the user after he/she signs-in).
HOWEVER, the most important is to secure your database (and other Firebase backend services, if you use them) with some Security Rules based on the role. If your backend is secured, a non-authorized user who succeeds in opening or reverse-engineering your Admin frontend app can maybe see the GUI elements but cannot read and modify the corresponding data.
Since you store the role in a Firestore document, you need to use, in your Security Rules, the get() function, in order to get the contents of the user document. See the example in the doc.
Having said that, another classical approach to set up a role-based access-right strategy is to use Custom Claims, as explained by #Ashish in his answer.
One main advantage of using a Custom Claim is that the role (the claim) is contained by the ID token and therefore no additional lookup to a Firestore doc is needed to check for admin permissions.
You should note that you can only set Custom Claims from a privileged server environment by using the Firebase Admin SDK. This means via a server you own or via a Cloud Function (see this article, for example). You could also use the new dedicated "experimental" extension.
Setting the roles through a Firebase doc, as you do, is easier (just a document write or update), but you need to correctly secure the collection, in order to avoid a malicious user can modify a user doc.
Another advantage of Custom Claims is that they can be used in the Security Rules of all the services (Firestore, Cloud Storage, RTDB). With role declaration via a Firestore doc, you should note that you cannot get this role in a Cloud Storage or RTDB Security Rule (you cannot read Firestore from Security Rules of the other services).
I am trying to use a 6 digit code to log-in a user.
The code is available for 20 seconds and is unique to every user.
Briefly explained:
User is already logged in on a mobile app
User press the button "Get Unique Code"
Then, user enter the code on a WebPage on his PC
If the code is correct, show data for that user
What am I asking is if there is way to properly authenticate the user who introduces that code correctly given that I have the userID and all the informations about the user?
I can try and "fake log-in" (display all the information for that user when the code is correct) but there are some issues with this and I would like to avoid it.
I am using Firebase Authentication and Firebase Firestore. JavaScript is used for Web.
You can implement any authentication scheme you want by creating a custom provider for Firebase Authentication.
See Authenticate with Firebase in JavaScript Using a Custom Authentication System and Creating Custom Tokens with the Admin SDK.
In this flow you:
Sign in the users yourself.
Create a custom token for those users in a trusted environment, such as a server you control, or Cloud Functions.
Pass that custom token to Firebase Authentication, which can then use it to identify the user, and secure access to Firestore, Storage, and Realtime Database.
I have to update a document from the settings menu of my web app. I'm using cloud firestore as my db service. When updating the document, I want to send those data with the verification password so that it will be re verifing the user before updating. This cannot be done in the front end because of the security reasons. Is there any way of doing it?
First of all you need to understand what you want to do?
If you need to deal with updating some document by current user (in our case user should be authenticated), so you can use Firestore Security rules. In short firestore rules help you to restrict access to your database: you can do check if user is authenticated or not, validate data before write and more. All these checks are being done on the server side, so you need not worry about your webapp. For more read official docs.
On the other hand you can use firebase cloud functions and manually send http request with Authorization header. To perform this action you need token from firebase. You can generate it by calling method on your currentUser. For more read this doc.
Edit: If you want re-verify with password you can signIn user with password again and do next operation
I've a requirement to integrate Auth0 in our project (Reactjs/Hapijs/MySQL). I checked the documentation and they have many examples and that is great, however, I can't find any related to how exactly do I use my existing user database.
In my application I have users and those users can have one or more projects. With the authorization that we currently use, a user logs in, I check what projects does he own and send it to the React application.
I am missing a document that explains me how to use Auth0 and still be able to check in my database what projects user owns.
My idea on how that should work (I might be wrong):
User sends username and password to our server
Our server makes request to Auth0 (with provided credentials)
Auth0 replies back to our server with some token
We look in users table in our database and try to verify the existence of that user
If it is a match then we simply look (as we already do) for user projects.
Is this how it is supposed to work?
There are a few options available for scenarios where you want to integrate Auth0 with applications that already have existing user databases. You can either:
continue to use your existing store
progressively migrate your users from your custom store to the Auth0 store
You don't mention it explicitly, but judging from your expected flow it seems you would be wanting to implement the first option. There is specific documentation that you can follow that explain how you can setup your custom database connection, see Authenticate Users with Username and Password using a Custom Database. It mentions MySQL, but others database servers are supported and there are many templates that will allow you to quickly setup things.
When you complete this the final flow will be the following:
Using either Auth0 authentication libraries (Lock) or your custom UI you'll ask the user for their credentials
Either Lock or your custom UI submits the credentials to Auth0 authentication API
Auth0 authentication API validates the credentials by calling scripts that execute against your custom database (these scripts were provided by you when you configured the database connection)
If the credentials are valid the Authentication API will return a token to the calling application that will have user information and proves the users is who he say he is.
The scripts you need to provide are the following, but only one is mandatory:
Login script (executed each time a user attempts to login) (mandatory)
Create user script
Verify email script
Change password script
Delete user script
The optional scripts are only required when you want to provide the associated functionality through Auth0 libraries, if only need the login to work then you can skip them. The login script, in the case of a valid user, is also where you return the profile information of the user, for example, you could in theory include their owned projects in the user profile.