Application-level data access authorizes a software identity to consume defined data. User-level data access authorizes a person. A delegated request connects both: the application acts for a signed-in user, and the delivery system must evaluate the relevant permissions of each. An application identity is not a grant to every record or field, and a developer’s personal access is not the application’s permission.
Choose the model by asking whose authority the operation needs. An interactive support screen should retain the agent’s identity and record boundaries. A scheduled regional digest may need an independently approved service identity. Giving both the same administrator credential hides that distinction and makes the resulting access difficult to review.
The matrices, application names, roles and field sets below are synthetic architecture examples. They show a recommended design, not Elementrix screens, configured permissions or observed test results. Verify the identity modes and enforcement behavior supported by your implementation.
Why a human account and an application identity differ
A person has employment responsibilities, team membership and a lifecycle such as joining, changing role or leaving. A software consumer has an operational purpose, deployment environment, owner and runtime identity. Its lifecycle includes redeployment, replacement and retirement. Keep these records separate even when one person develops, owns and uses the application.
Authentication establishes the caller’s identity. Authorization decides what that caller can do with a resource. Successfully signing in, registering an application or obtaining a token does not by itself establish permission to read every customer attribute. For the broader control concepts, see our data access control guide.
| Design question | Human account | Application identity |
|---|---|---|
| Who is acting? | A named person using an approved client. | A registered workload or service. |
| What establishes accountability? | Business role, team and manager. | Business sponsor, technical owner and deployment environment. |
| What should the grant describe? | Permitted operations, records and fields for the person’s task. | Permitted operations, records and fields for the service’s purpose. |
| What ends access? | Role change, departure or withdrawal of the human grant. | Retirement, scope withdrawal or end of the approved service use. |
| What does a credential prove? | Possession of an accepted authenticator for that account. | Possession of an accepted workload credential; not unlimited authorization. |
Delegated user access versus service access
Delegated access: preserve the person behind the request
Use delegated access when a user’s authority must constrain the operation. The API needs reliable application and user context, then checks the operation, requested record and response fields. Do not authorize by taking the union of every privilege the application and user happen to possess. A highly privileged user should not make an unrelated application entitled to every field.
Microsoft Graph’s authentication and authorization overview distinguishes delegated calls on behalf of a signed-in user from app-only calls made with the application’s identity. Its delegated model requires the client and user to be authorized. This is a concrete reference model; other APIs can implement different policy rules, so check their contract rather than assuming the same token claims or consent flow.
Service access: authorize a defined workload
Use a service identity for a task designed to operate independently of a signed-in person. Approve its business purpose, named data scope and responsible owner explicitly. Avoid automating a person’s login or borrowing an administrator account to keep a batch job running. Separate production and test identities when those environments require different data or controls.
The OAuth 2.0 client credentials grant is intended for confidential clients. It is not a browser application’s shortcut for embedding a shared secret. A public client cannot keep such a secret confidential. Choose a supported identity flow for the client type and keep credential material out of distributable client code.
A service grant does not disappear merely because the engineer who created it leaves. Conversely, removing the engineer’s account should not be your only plan for shutting down a retired service. Track the runtime identity and grant directly, with an owner who can review and withdraw them.
Map owner, app, purpose, and approved data
Use one grant inventory that distinguishes runtime consumers from the people who request, approve or operate their access. The synthetic customer-service product contains customer_id, account_status, contact_email, preferred_language and service_region. Its owner approves different subsets for an interactive support portal and a regional digest.
| Identity / role | Access path | Approved data | Record boundary | Accountability |
|---|---|---|---|---|
| support-portal | Delegated client ceiling; a user decision is also required. | customer_id, account_status, contact_email, preferred_language. | Only records permitted to the current user. | Customer Operations sponsor; Portal Engineering owner. |
| regional-digest | App-only service; no signed-in user supplies authority. | customer_id, account_status, service_region. | REGION-A records only. | Regional Operations sponsor; Data Platform owner. |
| Support Agent | User acting through support-portal. | The portal’s four fields for the assigned support task. | Cases assigned to that agent. | Support Operations manager. |
| Support Supervisor | User acting through support-portal. | The portal’s four fields for team supervision. | Cases in the supervised team. | Customer Operations manager. |
| Security Reviewer | Review of grant metadata, not a customer-data consumer. | Request, decision and grant metadata only; no customer field grant. | Applicable review records. | Security Governance lead. |
The first two rows define application boundaries. The next three define human responsibilities in this design. They are not five interchangeable credentials. The reviewer’s authority to inspect or approve a grant does not automatically include access to its customer payload. If a reviewer needs operational data, assess and grant that separate use explicitly.
For the support portal, combine the application’s allowed operation and field ceiling with the agent’s permitted records and any field restrictions on the human grant. The result can be narrower than the portal ceiling. For regional-digest, evaluate its service grant directly; a supervisor’s portal permissions cannot be borrowed to expand the digest.
Keep a reviewable grant record
- Stable application or user identifier, identity issuer and relevant environment.
- Access mode: delegated or app-only; for delegated access, the required user context.
- Business purpose, accountable sponsor and technical owner.
- Product/version, allowed operations, approved fields and record boundary.
- Approval reference, grant revision, review date and conditions for withdrawal.
- Provisioning reference and evidence that actual responses respect the grant.
A purpose statement explains why a grant was approved; it is not a magic token claim that proves each request is justified. Decide which conditions are technically enforceable and which require an operational review. Our data access approval workflow guide connects the request, decision, provisioned grant and delivery checks.
Separate applications with different field needs
The support portal needs contact_email to contact an assigned customer and preferred_language for the interaction. The regional digest needs service_region to organize operations, with no reason to retrieve the contact address. Keeping one reusable product does not require distributing its entire schema to both consumers.
Return only the allowed subset at the delivery boundary. A hidden screen column is insufficient if the API response still contains the value. Enforce record boundaries as well: removing email while returning every region’s records does not complete the design. Our field-level security guide explains the field dimension of that control.
| Request case | Expected decision | Evidence to retain |
|---|---|---|
| Support Agent requests an assigned case through support-portal. | Allow the four permitted fields when all required user and client checks pass. | User ID, client ID, grant revision, case boundary and returned field names. |
| The same agent requests a case outside their assignment. | Deny the unauthorized record; client approval alone does not permit it. | Attempted record boundary, decision and enforcement path. |
| regional-digest requests contact_email. | Deny or omit that field according to the documented API contract; never expose its value. | Service identity, attempted field and actual response. |
| Security Reviewer calls the customer-data endpoint. | Deny without a separate customer-data grant, even if the person can review grants. | Review role, runtime identity and authorization decision. |
| A caller changes a client ID, user ID or region in the request body. | Do not trust the change as authorization context; use validated identity and policy. | Validated caller identity and result of the negative check. |
These are acceptance criteria, not passed tests. Add actual outcomes only after exercising the delivery paths. Include prepared exports, caches and downstream services in the review where they can expose the same data. Preserve useful audit references while avoiding unnecessary sensitive payloads in logs.
The OWASP Authorization Cheat Sheet recommends least privilege, denial by default and permission validation on each request. Use those principles when reviewing both the human and service paths; authenticating the application once should not turn later resource checks into an assumed allow.
Review identity changes and credential rotation
Rotation changes the authenticator, not the approved purpose
Keep a stable consumer identity separate from its current credential. In a planned rotation, introduce the new authenticator through the supported process, test that it maps to the intended identity and grant, then retire the old one. Keep any overlap bounded and observable. Rotation should not silently create a new, broader grant or duplicate permissions.
Removing a secret does not necessarily invalidate every token already issued with it. Review token lifetimes, authorization caches, active sessions and the implementation’s revocation behavior. Where immediate withdrawal is required, identify the controls that stop new delivery and verify them. Do not promise instant revocation until those paths have been tested.
| Change | Review and action | Verification question |
|---|---|---|
| Agent changes team or leaves. | Remove or revise the human scope; review active sessions and pending work. | Can the former assignment still retrieve data? |
| Application gets a new owner. | Reconfirm sponsor, purpose, scope and operational responsibility. | Is the new owner accepting the same grant or requesting a different use? |
| Credential rotates. | Verify identity mapping; retire the old credential and consider issued tokens. | Does the new authenticator retain only the intended scope? |
| Application is retired. | Withdraw its grants, stop workloads and retire credentials through supported controls. | Do alternate routes or existing tokens still return data? |
| Purpose or requested fields change. | Treat the change as a grant review, not routine credential maintenance. | Was the new scope approved and enforced before use? |
Assign a review date to each consumer and retain the result. An application with no active owner, no current purpose or a scope that no longer matches its job needs a decision, not an automatic renewal. Keep human access reviews and service grant reviews connected, but do not assume one substitutes for the other.
Choose the identity model before granting fields
Start with one consumer and one data product. Decide whether the task must run with a user’s authority or with its own service authority. Document the approved fields and records, then run positive and negative delivery checks. This creates a concrete contract that owners, API teams and security reviewers can evaluate.
Request an Elementrix demo to discuss how an application’s approved fields can govern a data response. Bring the two-app matrix and ask which identity modes, field decisions and credential lifecycle controls the current implementation supports. Verify those details before treating the example as an implementation guide.