I'm assuming both authentication and authorization are requirements, if you don't know then you should raise it as a risk and make it clear you could end up with significant re-writes.
Assuming you have requirements you don't have to build authentication and authorization into an application right away, many prototypes have no security at all because they will never be accessible to the outside world. Before an application is going to be in production it will need to have its security requirements met or you risk a breach.
Before you start delivering code you need to have a security model, and understand how you are going to deliver security in code or you may have to re-write the whole thing later. How are you going to filter information based on role? Do you know the roles, and what access restrictions need to be put in place? Are you collecting all the data you need to implement your security model? Do you need row filtering, or column level filtering as well? Will databases or buckets be accessed directly by users or is will restrictions be implemented in the application code? If you don't know my advice would be to stop until you do.
Clients live in the now, as in they want it now, and can't understand why you can't deliver it now. It's your job to tell them what it will take to do it right, and make sure they understand the risks of rushing it, and their job to take the risk. Make sure you get it all in writing, so they can't come back to you later.