I want to address 3 separate security layers here.
First there is connection-level security. This answers the question: Can someone other than the client and the server see the data transmitted. Using HTTP, any device that can see your traffic (other wifi users, routers between client and server) can intercept the data and read it because it is plain text. HTTPS helps address this concern by encrypting the data so that even though it can be intercepted, it can't be understood (practically speaking). Also, HTTPS is still not considered secure unless you get a signed certificate. A signed cert is essentially being vouched-for by a trusted authority.
Second, there is Authentication. Can a particular client access my application? Having only HTTPS, any client (e.g. browser navigating to URL) can still access the data. You have to add an authentication (login) to your application so that you can tie that particular client to a valid user of the system. Common today is token-based authentication where you issue a token when the user successfully authenticates. Then the token is sent with each request to identify the user. To be secure, this requires HTTPS. Otherwise, the token can be read, copied, and used by any listener. Search terms here are
Third, there is Authorization. Having only Authentication, you can say it's a valid user of the system, but you still cannot say what that user is able to do in the system. If all users are capable of the same actions, then Authentication is enough. However, if some users have different operations available from others, then you also need Authorization to instruct your server what the user is allowed (authorized) to do. The common way to do this is either by Roles or Claims. When the user is authenticated, often the user's authorization (role or list of claims) is also loaded into memory. Subsequent requests with the same token can look up the user's authorizations to decide whether or not they can perform the given operation in the system. Search terms here are