Permissions
Part of No-code app integrations
Limiting API credentials to the app's needs
Map app tasks to API permissions, distinguish user and unattended access, protect credentials and check that excess actions are denied.
List the API operations an app must perform, the data each touches, and whether it acts for a signed-in person or runs unattended. Request the narrowest permission the provider supports. Check both the credential's scope and the account behind it: either may grant more access than the task requires.
Map tasks to access
| App task | Needed action | Access question |
|---|---|---|
| Show a case status | Read a case | Can access be limited to cases this user may see? |
| Add a note | Create a note | Is permission to edit or delete the case necessary? |
| Run a nightly import | Read selected records | Which identity can safely run without a signed-in user? |
The table records what to request; it does not prove the provider offers each boundary. Some APIs have narrow scopes; others are broad and depend on the connected account's permissions. If the necessary boundary is unavailable, document the excess access and ask the system owner whether a more limited account or another route is appropriate.
Microsoft Graph illustrates two permission models. Delegated permissions let an app act for a signed-in user within both its granted scope and that user's access.
Application permissions support app-only access, where the app calls Microsoft Graph with its own identity, without a signed-in user. Another API may use a different model.
Delegated vs Application Permissions in Microsoft Graph
- Delegated PermissionsApp acts on behalf of a signed-in user within the user's granted scope and access rights.
- Application PermissionsApp runs without a signed-in user, using its own identity. Suitable for unattended processes.
Mapping App Tasks to Minimal API Access
- Identify required API operationsList each task the app must perform.
- Determine data touchedSpecify which records or resources are involved.
- Distinguish user contextDecide if the action is for a signed-in user or unattended.
- Request narrowest possible permissionUse scopes that match only what’s needed.
- Verify both credential scope and account permissionsEnsure neither grants more than necessary.
Keep the credential under control
Use the platform's supported connection or secret facility and limit who can change or retrieve the credential. In an app with client-side screens, check that a secret is not embedded in content delivered to users. Keep development and live credentials separate. For unattended work, settle ownership and departure arrangements before relying on a staff member's personal account.
Record the connection owner, intended operations, review date and revocation route. Keep API keys and tokens out of app fields, shared documents, URLs, error messages and logs. OWASP requires non-public REST services to perform access control at each API endpoint. Hiding a button in the app does not stop a caller from trying the underlying API operation.
Check and maintain the boundary
With fictional data, check a permitted call and an action outside the approved scope. Confirm that the API refuses the latter; an absent screen control is insufficient.
If users share a connection, check whether its identity can see more data than each user should and how the app and API enforce the user's permitted records. Power Apps, for example, shares some connections with an app while other connection types require each user to create one.
Plan how to rotate and revoke credentials before they expire or an owner leaves. OWASP addresses the need to centralise the storage, provisioning, auditing, rotation and management of secrets to control access to secrets and prevent them from leaking. Repeat the permitted and denied checks after a scope or account change.
Key Security Principles from OWASP and Microsoft
- Access control at every endpoint
- Required for non-public REST services.
- Centralised secret management
- Includes provisioning, auditing, rotation, and storage.
- No reliance on UI hiding
- Hiding buttons does not prevent API calls.
- Regular boundary validation
- Test permitted and denied actions after changes.
