ASD ISM 2139 Central logging of third-party OAuth consent, token issuance and use
What it says
Consent grants, token issuance and token use for third-party OAuth applications are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSend every third-party OAuth consent grant, token issuance and token use event from your identity platform to one central log store so app access can be traced and investigated.
Third-party OAuth applications are external apps (for example a scheduling tool, a mail add-in or a reporting service) that a user or administrator allows to act on their behalf in your environment. That permission is given through a consent grant, the identity platform then issues an access or refresh token to the app, and the app uses that token each time it reads mail, files, contacts or other data. This control requires all three of those events (the consent grant, the token issuance and the token use) to be recorded in a central log, not left scattered inside the identity platform's own console or inside each application. It matters because attackers increasingly abuse OAuth rather than passwords. A phishing page can trick a user into consenting to a malicious app, or an attacker who compromises one account can register an app and grant it broad permissions. From that point the attacker holds a token that keeps working even after the password is reset or multi-factor authentication is enforced. If consent, issuance and use are not logged centrally, that access is invisible: nobody can see which app was approved, when it received tokens, or what it has been doing with them. Central logging is what lets security staff see the full chain of events in one place, correlate it with other activity and investigate quickly.
Free. Save your status, tasks and notes.
Why it matters
Without central logging of OAuth consent, token issuance and token use, a malicious or over-permissioned third-party application can retain silent access to mailboxes, files and APIs for months. Investigators cannot establish which user consented, which permissions were granted, when tokens were issued or what the app accessed, so incident response is slow or impossible, data breaches go undetected, and the organisation cannot demonstrate to auditors or regulators what an external app did with its data.
How to implement
Identity administrators enable audit and sign-in logging for OAuth consent grants (both user consent and admin consent) in the identity platform, then confirm each consent event records the user, the application, the permissions requested and the time.
Identity administrators enable logging of token issuance for third-party applications, including access and refresh token issuance from service principal or application sign-ins, and verify the events capture the application identity and the scopes granted.
The security operations team configures the identity platform's diagnostic or export settings to stream consent, token issuance and token use (service principal and application API activity) events to the central logging platform or SIEM, rather than leaving them only in the source console.
The logging team defines retention and parsing for the OAuth event categories in the central store so token use events are not dropped by volume filters, and builds a simple query or dashboard that shows the three event types side by side per application.
The identity and logging teams add a health check (for example a scheduled query that fails if no OAuth consent, issuance or use events have arrived in the expected window) and add OAuth log forwarding to the change checklist for any identity tenant, SIEM or licence change.
Keep it running
In practice this control lives in the identity platform (for example Microsoft Entra ID, Google Workspace or Okta) and the central logging platform or SIEM. The identity platform already generates consent, token issuance and sign-in or API-use events; the day-to-day work is making sure those event streams are switched on for third-party (non-first-party) applications, forwarded to the central log store, and kept flowing.
Operational rhythm typically includes: confirming the log forwarding connector is healthy and has not silently stopped, checking that new application registrations or consent events appear in the central store shortly after they occur, and confirming the three event categories are all present rather than only one or two. Token use events are usually the highest volume and the most likely to be trimmed for cost, so the retention and filtering settings for those streams need to be watched so the "use" part of the control is not quietly lost.
Owners are normally the identity or platform team for the source configuration and the security operations or logging team for the central store. Changes to either side (a new tenant, a new SIEM, a licence change that affects log export) should trigger a check that OAuth events are still arriving.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the identity platform's logging or diagnostic configuration that covers third-party OAuth applications.
Look at
Check whether consent grant, token issuance and token use (application or service principal sign-in and API activity) categories are all enabled and set to export to a central destination.
Good evidence
All three event categories are enabled and pointed at the organisation's central log store or SIEM, not just retained in the identity console.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a sample of recent consent grant events pulled from the central logging platform, not from the identity console.
Look at
Confirm the records show which user or administrator consented, which application, which permissions were granted and when.
Good evidence
Consent events for third-party apps are present in the central store with enough detail to identify the user, application and permissions.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a sample of token issuance events for a named third-party application from the central log.
Look at
Look for records of access or refresh tokens being issued to that application, including the scopes and the time of issuance.
Good evidence
Token issuance for the application is visible in the central log and can be matched back to the earlier consent grant.
- Check 4 of 5What an auditor asks for
Ask for
Ask for evidence of token use activity for the same third-party application in the central log.
Look at
Check that the application's use of its token (API calls or resource access made under the app's identity) is being captured, and that volume filtering or retention settings have not excluded it.
Good evidence
Token use events are present and retained, so an investigator can see what the application actually did after it received a token.
- Check 5 of 5What an auditor asks for
Ask for
Ask how the organisation knows the OAuth log feed is still working.
Look at
Look for a health check, connector monitoring or a recent test showing that consent, issuance and use events continue to arrive at the central store.
Good evidence
There is a documented or automated check that would surface a broken or paused OAuth log feed, and it has been exercised recently.
Mappings
Closest match in ISO/IEC 27001: A.8.15, Logging of activities and events, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.15.
ISM-2139 requires that third-party OAuth consent, token issuance, and token use events are centrally logged for traceability and investigation. ISO/IEC 27001:2022 Annex A 8.15 is broader, requiring logs of activities and relevant events to be produced, stored, protected, and analysed across systems generally. ISM-2139 is a specific, identity-provider/OAuth-focused instantiation of the broader logging control in Annex A 8.15.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.