Authentication vs authorization: what changes between logging in and having permissions

Published on 2026-10-20 by frfrand

Autenticación confirma quién sos y autorización decide a qué podés acceder: ejemplos, fallos y formas de probar permisos.

Authentication is verifying who is attempting to access an application. Authorization is deciding what that identity can do. They are two different questions, and confusing them causes serious security errors.

When you log in to a panel and enter your password, the system attempts to recognize your identity. Once inside, deciding whether you can check another customer's billing is a different problem.

The building example

Imagine a company with a reception and several offices. To enter, you show your employee card: that identifies who you are. But the card should not automatically open the director's office, the warehouse, and all confidential files.

Authorization establishes those restrictions. A person can log in correctly and still receive an error when trying to access a function for which they do not have permission.

What mechanisms are used for authentication?

A password, a security key, a valid session, or an external login system can participate in the process. There are also ways to combine factors to make account theft more difficult.

No method is perfect. A session can be stolen, a reused password can be leaked, and a misconfigured integration can accept identities it should not.

That is why it also matters how sessions are revoked and how anomalous accesses are detected.

How is authorization applied?

An app can use roles such as reader, editor, or administrator. But in multi-tenant applications, checking the role is not enough: you must validate which organization or specific resource the data belongs to.

For example, someone can be an administrator of company A and have no access to company B. An endpoint that only verifies role=admin and forgets to check the company can expose information from other clients.

The control must run on the server side, not just by hiding buttons on the frontend.

A typical case: changing an ID in the URL

Imagine that an API allows querying an invoice via /invoices/123. A person logs in legitimately and changes the number to 124.

If the backend returns an invoice from another account without checking the owner, there is an authorization problem. It is the type of error that can occur even if authentication works perfectly.

The solution consists of applying permissions on each sensitive operation and resource, and testing both allowed and prohibited cases.

What about a valid token?

A token can help identify a person or client, but valid does not mean authorized for everything. You must check its scope, expiration, audience, and the actual permissions of the operation.

Authorization can also change during a session: someone loses access to a project and the system needs to stop allowing actions that were previously legitimate.

How to test it before publishing

Prepare users with different roles and organizations. Try to access the resources that belong to them and then those that do not. Verify that the server responds correctly, without leaking private data.

Don't settle for the test of "the administrator can open the panel." It is equally important to verify that a reader cannot delete records and that a user from one company cannot query another.

Where does ArduMaker come in?

ArduMaker organizes projects and resources by companies and teams. The principle is the same: recognizing an account is not enough; every operation on a VPS, application, or data must respect the corresponding permissions and business scope.

In short: authentication answers "who are you?". Authorization answers "can you do this?". An application needs both and must check the second one on every sensitive access.

Sources: OWASP Authorization Cheat Sheet · OWASP Authentication Cheat Sheet.