How does login work in an app? A beginner's explanation

What actually happens when you log in?

You open the app, type your mobile number, a four- or six-digit code arrives, you type it, and you are in. It takes seconds, but behind it is a chain of steps whose purpose is for the app to know who you are, make sure you are really you, then remember you as you move between pages.

Illustration

We will use one example throughout: a small coffee store with three kinds of users: the customer who orders, the staff member who prepares orders, and the owner who sees everything. All three sign in, but each sees something different.

If you are learning how apps work, this article is part of a series that starts with learn programming by building apps and includes the database where your account is saved.

What is the difference between identification, authentication and authorization?

Three words beginners often mix up. Understanding the difference is half of understanding login:

Authentication happens once, at sign-in. Permissions are checked on every request. When a staff member presses "View orders", the server asks: is this staff? When they try to open the profit report, it asks: is this the owner? So someone can sign in successfully and still be blocked from a page, which is exactly right.

What are the common ways to log in, and which suits my app?

Each method proves who you are with something different: something you know, like a password; something you have, like your phone; or a trusted account elsewhere:

How does the app remember me after I sign in?

Imagine the app asking for a code on every page. Impossible. So once you have proved who you are, the server gives you a session: a temporary digital pass, like an event wristband, that your browser or app keeps and sends automatically with every request.

1. 1
   1You prove who you are

   You type your number and the code; the server checks the code is right and has not expired.

2. 2
   2You get a session

   The server creates a unique, hard-to-guess pass, links it to your account and sends it to your device.

3. 3
   3You move freely

   With each page your device sends the pass, and the server knows it is you without you typing anything.

4. 4
   4The session ends

   When you sign out, or after a set time, the pass stops working and you are asked to sign in again.

That is why a shopping app keeps you signed in for weeks while your bank logs you out after minutes. Session length balances comfort and safety: a coffee store can remember you for a month, while a dashboard with financial data should use a shorter one.

How are passwords and codes kept safe?

The golden rule: a well-built app does not know your password. Passwords are never stored as typed. They go through a one-way transformation that produces scrambled text which cannot be reversed. When you sign in, what you typed is transformed the same way and the two results are compared. If the database were stolen, the thief would not find the passwords themselves.

• Short-lived codes: a phone code should expire within a few minutes.
• Attempt limits: after a few wrong tries, acceptance pauses, so nobody can try every number.
• Limits on sending codes again: so nobody uses your app to send thousands of messages at your expense.
• An encrypted connection: everything between the device and the server travels encrypted.
• Generic error messages: "Incorrect code", without revealing whether the number is registered.

What are roles and permissions, and why are they checked on the server?

In the coffee store, customers see products and their own orders, staff see new orders and change their status, and the owner sees everything, including profits and settings. Instead of setting permissions person by person, you give each user a role, and each role a set of permissions. This is called role-based access control.

The key point for beginners: hiding the "Profit report" button from staff on screen is not enough. If a staff member knows the page address and types it in, the server must refuse. Real permissions are checked on the server on every request; the screen only reflects them. It is a perfect example of frontend vs backend.

How do I add login to my app in Fanann?

Building login by hand from scratch is sensitive work: codes, sessions, attempt protection, roles. In Fanann, phone-number sign-in with a one-time code comes ready with the database, and you can ask for email and password or Google sign-in. All you do is describe who signs in and what each role sees.

After building, give the QA Engineer your app's address so it signs in with different roles, tries to open pages that are not theirs, and sends a report with screenshots and the severity of each bug.

How do I understand login through my own app?

The best way to understand login is to trace it in your own app. Open your project's code (the project is yours to read and export) and try these exercises:

• Trace the journey: from the number entry screen, to the request sent to the server, to the place where the code is checked.
• Ask Neo: "Where is the owner permission checked? What happens if a customer tries to open the dashboard?"
• Try it yourself: sign in as a customer in one window and as the owner in another, and compare.
• Request a change: "End the owner dashboard session after one hour", then find the file that changed.

Knowing who you are is one thing; trusting what you ask for is another. A safe app asks both questions every time.

To go deeper into managing staff and their access, read roles and permissions for your team.

Frequently asked questions

Terms in this article