Authentication · Authorization
Authentication / Authorization
What is authentication?
- Authentication = verifying who you are
- Authorization = what you are allowed to do
- Two pillars of security
Once you separate authentication from authorization, you check different things. Authentication happens once, at login, but authorization has to be decided again on every request. Even when a logged-in user opens an order detail page, the server must confirm on the spot that 'this order really belongs to this person.' Hiding menus and buttons on the screen is not authorization — anyone can still get in by typing the URL directly or calling the API as is.
Separating methods from models keeps the design simple. Authentication methods fall into what you know (a password), what you have (an OTP or passkey), and what you are (a fingerprint or face); combining two different kinds gives you multi-factor authentication (MFA). On the authorization side, the split is between RBAC (role-based) and ABAC (attribute-based, which also weighs conditions). Rules such as blocking access outside working hours or allowing bulk downloads only from the corporate IP belong to the latter. The names are easy to confuse, but OAuth 2.0 is an authorization protocol; the identity layer that tells you 'who the user is' is OIDC, built on top of it.
In operations, lifecycle management is the real day-to-day work. A common setup keeps access tokens short-lived (15–30 minutes) and renews them with refresh tokens, and the baseline is least privilege: default permissions to 'deny' and open up only what is needed. But incidents more often start with accounts than with tokens — whether permissions change when someone leaves or moves departments determines the real level of risk. If your service handles personal data, you must keep records of permission grants, changes and removals, along with access logs, for at least one year.
Most real incidents happen in the gap where authentication passes but the authorization check is missing. The classic case: change the order number or user id in the URL by 1 and someone else's statement opens right up. In development, teams usually test with a single account, so the flaw stays hidden until just before deployment. Sharing one admin account across a team has the same root cause. When an incident occurs, you cannot prove who viewed what and when, and the burden of proof for accountability falls squarely on the company.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”| Category | Authentication | Authorization |
|---|---|---|
| What it verifies | 'Who are you?' | 'What are you allowed to do?' |
| Order | First | After authentication |
| Yes | Log in | Access levels and permissions |
A basic computer security concept, rooted in the access control principle of separating 'identity verification (authentication)' from 'granting permission (authorization).'
Consider a hypothetical case: Company A, a logistics SaaS firm with 210 employees and annual revenue of about KRW 40 billion (≈ US$29,926,700). It runs a shipment-tracking portal used by 340 shippers, and a regular security audit by a major client found that 'other shippers' waybills can be viewed.' Contract renewal was two months away.
- During the review, the client's security officer changed one digit of the shipper code in the URL, and over 1,200 waybills from other companies appeared. Company A's dev team lead answered, "It went through because the user was logged in," and then had nothing more to say.
- That week, the CTO audited all 180 API endpoints and found 47 that return data without verifying ownership, most of them code carried over from the initial version two years earlier.
- On the backend, the team redefined roles into three types — shipper, warehouse and internal operations — and added shared middleware that returns 403 whenever the company code in the token differs from the company code being queried, applying it across all 47 APIs at once.
- The information security officer linked accounts to the HR system and deactivated 34 live accounts of former employees and 9 accounts of an outsourced development vendor. They then split 4 shared admin accounts into 11 individual accounts and set up a quarterly permission review.
- In the re-audit three months later, APIs without permission checks were down to zero. With one-year access-log retention in place, the time to respond to client security audits dropped from 3 weeks to 5 days, and the contract was renewed as is.