Why Authorization Is the Hardest Step in Digital Services Despite Effortless Logins

Opening a new app, entering a phone number, scanning a face, and confirming a verification code usually takes only a few seconds. This ease creates an illusion: once identity is verified, the rest of the business flow should follow naturally.

Reality is the opposite. The more digital services pursue "seamless" experiences, the more authorization gets hidden inside a prompt, a pre-checked box, or a casual confirmation. When disputes arise, systems can prove "this account logged in" but cannot clarify: was this operation the user's true intent? Where did the permission come from? Did the scope exceed boundaries?

This is also a change worth revisiting after China's National Network Identity Authentication Public Service Management Measures took effect in July 2025 and continue to expand. The measures do not force all services into a single login method; instead, they extract "real-name identity verification" from the repeated collection of plaintext personal data by individual platforms, offering a more standard, optional public capability.

The real focus is not whether login loses another step, but that identity, authorization, and responsibility finally have a chance to stop being conflated.

A Common Misconception: Authentication Passed ≠ Authorized to Proceed

Identity authentication answers "who is initiating the request right now." It provides a starting point for trust but cannot automatically answer every business question.

For example, the same verified user may browse public information but not view a sensitive archive; may submit an application but not confirm on behalf of a family member; may enter an account but not change critical settings. What is missing is not another authentication, but a more specific authorization.

If the three are mashed together, products often produce two opposite experiences: users are repeatedly asked for identity documents on one side, while critical actions are reduced to a vague "confirm" on the other. The former increases exposure; the latter increases unclear responsibility.

The Management Measures draw an important boundary: when retention of legal identity documents is not required, platforms may obtain only the verification result; only when collection and retention are necessary should they provide data on the basis of authorization or separate consent, following the minimization principle. The emphasis is on need-based verification, not "get identity and get everything by default."

The Real Challenge: Breaking "Access" into Three Questions

Traditionally, many systems treated permissions as role tables: admin, regular user, auditor. Today's service scenarios are more complex: cross-device operations, proxy relationships, automated workflows, temporary authorizations, and multi-party collaboration are increasing. Roles remain important but no longer suffice to explain a specific operation.

A more practical judgment is to break a key action into three questions:

Who is initiating? This is the identity and authentication question.

In what capacity and scope can they initiate? This is the authorization and delegation question.

What did the system actually execute, and can it be reviewed? This is the responsibility and audit-trail question.

None of these three questions can be automatically replaced by another. No matter how strong authentication is, it cannot substitute for authorization; no matter how granular authorization design is, it cannot substitute for an auditable execution record.

A Reference "Action Triad"

Layer 1: Identity

Question it must answer: Who is the initiator? Is verification valid?

Evidence to retain: Verification method, time, result

Layer 2: Authorization

Question it must answer: Why is this action allowed? What is the scope?

Evidence to retain: Authorization source, object, validity period, scope

Layer 3: Execution

Question it must answer: What did the system actually do?

Evidence to retain: Operation content, result, exceptions, rollbacks

Layer 4: Responsibility

Question it must answer: Who can explain when a dispute occurs?

Evidence to retain: Rule version, approval or confirmation chain

The value of this breakdown lies not in adding forms but in reducing gray zones. For instance, a high-risk operation needs clearer secondary confirmation; a short-term proxy needs a delegated relationship that can expire; an automated execution needs traceable rules and exception logs. If all three types of questions are solved only by "please log in again," the result is often neither smooth nor reliable.

Convenience Is Not Default Permission, But Respect for Choices

The Measures explicitly state that the application and promotion of Network IDs and Network Certificates follow the principle of voluntariness; platforms accessing the public service must also guarantee that users who do not use Network IDs or Certificates but complete registration and verification through other legal means enjoy equal service.

This point is easily overlooked. A good identity system does not push users into a single channel but gives them understandable choices in different scenarios: what information is used only for verification, what information will be stored, which functions remain available after refusing a certain authorization, and when consent can be withdrawn.

From a product perspective, this forces services to change "default agree" into "understandable agree." From a governance perspective, it makes the principle of minimum necessity land on every data exchange, every function call, and every permission change.

When Intelligent Processes Act on Behalf of Users, Authorization Must Come Before Login

The next scenario worth vigilance may not be a person logging into a system, but a system completing operations on behalf of a person: auto-filling forms, workflow routing, reminder escalation, cross-system queries. These capabilities raise the importance of identity authentication but also amplify gaps in authorization design.

An automated process may be triggered by a qualified user yet access data beyond the original task scope in subsequent execution; every step may "verify successfully" but no one bears explanatory responsibility for exceptions. The problem is not automation itself, but mistaking "who initiated" for "what the system is allowed to do."

Therefore, truly mature digital services of the future may not be those with the shortest login pages, but those that let users, operators, and auditors all see clear boundaries: identity is not over-collected, authorization is not silently expanded, and critical actions do not rely on post-hoc guesswork.

Login will increasingly resemble infrastructure. The real differentiator may be a more basic question: for every critical operation, can the system clearly explain "why you, why allowed, what happened afterward"?

Sources and Basis

Measures for the Administration of National Network Identity Authentication Public Services , China Internet Information Center, published May 2025, effective July 15, 2025.

Q&A by relevant officials of the Ministry of Public Security on the Measures for the Administration of National Network Identity Authentication Public Services , China Internet Information Center, explaining legislative background, usage principles, and boundaries.

One Year of Implementation of the Measures for the Administration of National Network Identity Authentication Public Services: Building a Digital Barrier to Protect Citizens' Personal Identity Information Security , Jiangsu Internet Information Office reprinting "Public Security Bureau Network Security Bureau" public information, July 2026, disclosing phased application progress. The judgments in this article are comprehensive analyses based on the above public materials.