What do authentica­tion and autho­riza­tion mean?

Authentica­tion and autho­riza­tion: the difference

The two terms are often confused but answer different questions. Authentication asks: who is this? Authorization asks: what may this person do? At the airport, the ID check corresponds to authentication, the boarding pass with flight and seat to authorization. Only both together get you on board.

The same order applies in software. First a user proves who they are, then the application checks for every action whether their role permits it. A successful login alone does not mean access to everything—and conversely, the best permission management is useless if identity is not verified reliably.

How it works

Authentication works through something you know (password), have (smartphone, security key) or are (fingerprint, face recognition). If at least two of these factors are combined, it is called two-factor or multi-factor authentication. Passkeys based on FIDO2 and WebAuthn replace passwords with cryptographic keys and protect better against phishing.

Authorization follows rules. In the role-based model (RBAC), each user gets a role such as “accounting” or “field service” with fixed rights. More flexible models take attributes such as department or location into account. The guiding principle is least privilege: everyone gets only the rights they need for their task.

Real-world example: a supplier’s customer portal

A supplier sets up a portal where customers retrieve invoices and delivery notes. Signing in with email, password and a one-time code is the authentication. After that, each customer may see only the documents of their own company, while sales staff may see all customers—that is the authorization.

A typical weakness: the invoice can be reached via an address such as /invoice/4711, and the application only checks whether the user is logged in, not whether the invoice belongs to them. By changing the number, they would see other people’s documents. The check must therefore take place on the server for every access.

Common mistakes and limits

Broken access control ranked first among web application risks in the 2021 edition of the OWASP Top 10. It is usually not the login that is at fault, but incomplete permission checks that are simply forgotten for new features. Common mistakes:

• Hiding rights only in the interface but not checking them on the server
• Shared accounts, so actions cannot be attributed to anyone
• Too many administrators and rights that are never withdrawn
• Weak passwords without a second factor for sensitive access
• No logging of logins and permission changes

What businesses should look out for

Define roles and rights during the design phase, grant only what is necessary and review access regularly. Sensitive access should be protected with two-factor authentication. Nano Concepts plans and programs login, role model and permission checks for portals, apps and web applications and tests them specifically for typical vulnerabilities.