Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/security/prefer-oauth2-over-api-keys-for-external-http-calls.md
Jesper Schulz-Wedde bfda67a95a
Promote security knowledge from community to Microsoft layer (#49) 
* Promote security knowledge from community to Microsoft layer

Pure git-mv relocation of the SECURITY domain from the community layer to the Microsoft layer. No content changes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address review feedback on security knowledge promotion

- do-not-grant-rights-beyond-a-users-entitlement.md: drop the See sample
  reference to a .good.al file that does not exist
- Remove the 'Contributions welcome' boilerplate line from
  compose-permission-sets, prefer-oauth2, and protect-sensitive-data
- protect-sensitive-data-in-temporary-tables: remove the pointless
  DeleteAll on the locally scoped temp buffer in the good sample and
  reword Best Practice to note local buffers are cleaned up automatically
- Drop guard-bulk-operations-with-istemporary from the promotion; it
  stays in the community layer pending a decision on whether it is security

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Remove Contributions welcome boilerplate from do-not-grant article for consistency

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-14 11:23:57 +02:00

1.8 KiB
Raw Permalink Blame History

bc-version domain keywords technologies countries application-area
all
security
oauth2
api-key
authentication
httpclient
token-refresh
al
w1
all

Prefer OAuth2 over API keys for external HTTP calls

Description

External HTTP integrations from AL can authenticate using OAuth 2.0 (client-credentials for service-to-service, authorization-code for user-delegated), API keys, basic authentication, or credentials in URLs. The mechanisms differ substantially in the blast radius of a leaked secret and in how cleanly tokens can be rotated. OAuth-issued tokens expire on their own schedule and rotate cleanly; API keys and basic-auth passwords typically have to be rotated manually and usually live unencrypted in a configuration table. When the partner supports OAuth, the difference is a material security improvement, not a stylistic preference.

Best Practice

When the partner supports OAuth, use the platform OAuth2 codeunit (AcquireTokenWithClientCredentials for service-to-service, AcquireAuthorizationCodeTokenFromCache for user-delegated flows) rather than hand-rolled token acquisition. Carry tokens and client secrets as SecretText, persist them only in IsolatedStorage, and refresh tokens proactively — on a buffer before the documented expiry — so routine calls never block on a token refresh.

See sample: prefer-oauth2-over-api-keys-for-external-http-calls.good.al.

Anti Pattern

Accepting an API-key or basic-auth integration because it is the first option documented, even when the partner supports OAuth. The shared secret usually ends up in a setup-table Text field, rotation becomes a manual operation that rarely happens, and a single disclosure exposes every tenant using the extension.

See sample: prefer-oauth2-over-api-keys-for-external-http-calls.bad.al.