Authentication vs authorization
Two words that sound alike and fail differently. Most AI-built apps have the first and are missing half of the second.
In short
Authentication is proving who someone is, for example by password, a one-time code or Google sign-in. Authorization is deciding what that authenticated person is allowed to do, such as which records they may read or change. Authentication happens once per session; authorization has to be checked on every request, on the server or in the database.
Also called: AuthN vs AuthZ
Why it matters when your prototype goes to production
Sign-in is the part everyone sees, so it is the part AI builders get right: add a provider, and users can log in. Authorization is invisible when it works and invisible when it is missing, because the interface only shows each person their own things. The data layer may still answer anyone who asks for someone else's.
| Authentication | Authorization | |
|---|---|---|
| Question | Who are you? | What may you do? |
| Example | Signing in with Google | Only editing your own invoices |
| Where it is enforced | The sign-in provider, such as Clerk | Your server and database, on every request |
| When it fails | Strangers get in | Signed-in users reach other people's data |
The second failure is the common one. Broken access control is first on the OWASP Top 10:2025.
Common questions
Is role-based access control authentication or authorization?
Authorization. Roles decide what a signed-in person may do; they say nothing about who that person is.
Does Clerk or Supabase Auth handle authorization?
They tell your app who the user is and can carry roles. The rules about which data each user may touch still have to be written in your server code or database policies.
Related terms
Read next
Sources
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.