Runbook: Defending Against the Axios NPM Zero-Day Supply Chain Attack with Microsoft Sentinel

Author: Lizet Pena De Sola

Created: 2026-04-10

Last Updated: 2026-06-02
Criticality: High
Estimated Duration: Immediate containment: 2-4 hours; full remediation and validation: 1-5 business days depending on environment size
Audience: Security operations, SOC Analysts, SOC Engineers, DevSecOps, platform engineering, application owners, incident response teams, and cloud security teams
Category: Supply Chain Security; Microsoft Sentinel; Threat Intelligence; Node.js; NPM

Purpose

This runbook provides a checklist-driven response and hardening guide for organizations defending against the Axios NPM supply chain compromise. The campaign involved malicious Axios package releases 1.14.1 and 0.30.4, a malicious dependency named plain-crypto-js, and cross-platform payload delivery associated with WAVESHAPER.V2. Use this document to coordinate containment, detection, threat intelligence ingestion, incident response, credential rotation, recovery, and long-term supply chain hardening. This was zero-day attack launched from March 31st, 2026; to April 2nd, 2026. This runbook was used as an example to conduct Security Incident Response activities on affected organizations.

Threat Summary

  • Impacted ecosystem: NPM / Node.js applications and build environments using Axios directly or transitively
  • Known malicious Axios versions: 1.14.1 and 0.30.4
  • Known safe rollback examples: 1.14.0, 0.30.3, or earlier known-good, approved versions
  • Malicious dependency: plain-crypto-js, including reported versions 4.2.0 and 4.2.1
  • Execution method: NPM post install hook executing an obfuscated JavaScript dropper
  • Target platforms: Windows, macOS, and Linux
  • Primary risk: Developer workstation, CI/CD, build server, package cache, and credential exposure leading to downstream compromise

Prerequisites

  • Access to source control, dependency manifests, lockfiles, SBOMs, and artifact/package registry logs.
  • Access to CI/CD platforms, build runners, container build images, and deployment logs.
  • Microsoft Sentinel workspace with relevant endpoint, identity, cloud, DNS, proxy, firewall, and Defender data connectors flowing.
  • Microsoft Sentinel Contributor or higher permissions to manage threat intelligence indicators and analytics rules.
  • Authority to isolate endpoints, pause pipelines, rotate secrets, block network indicators, and rebuild affected systems.

Severity and Activation Criteria

Activate this playbook if any of the following are true:

  • Axios version 1.14.1 or 0.30.4 appears in source repositories, package lockfiles, SBOMs, container images, deployed applications, developer machines, or CI/CD environments.
  • plain-crypto-js version 4.2.0 or 4.2.1 appears in dependency trees or package caches.
  • Node.js, npm, yarn, pnpm, or build processes spawned shell, PowerShell, curl, bash, zsh, Python, or suspicious child processes during package installation.
  • Any known command-and-control indicator, file hash, suspicious payload path, or persistence artifact is observed.
  • Secrets, tokens, cloud credentials, signing keys, or npm tokens were present on a system where the compromised dependency may have executed.

Phase 1: Immediate Containment Checklist

  • [ ] Open a high-severity incident and assign SOC, DevSecOps, platform, and application owners.
    Owner: Incident Commander
    Evidence: Incident ID
  • [ ] Pause nonessential CI/CD pipelines that build or deploy Node.js applications until dependency checks are complete.
    Owner: DevSecOps
    Evidence: Pipeline freeze record
  • [ ] Block known C2 domain and IP indicators at DNS, proxy, firewall, EDR, and cloud egress controls.
    Owner: Network Security
    Evidence: Change ticket / policy ID
  • [ ] Configure private package repositories to deny/remove use of known malicious Axios versions and the malicious dependency.
    Owner: Platform Engineering
    Evidence: Registry policy
  • [ ] Identify systems that executed package installation during the exposure window and prioritize them for isolation and triage.
    Owner: SOC / Endpoint
    Evidence: Device list
  • [ ] If plain-crypto-js is detected, treat the host or build environment as compromised until rebuilt or fully remediated.
    Owner: Incident Response
    Evidence: Containment decision
  • [ ] Preserve relevant logs, dependency manifests, lockfiles, build artifacts, EDR telemetry, and network logs before cleanup.
    Owner: Forensics
    Evidence: Evidence location

Phase 2: Dependency Exposure Assessment Checklist

  • [ ] Search source repositories for direct Axios version references.
    How to validate: Review package.json, workspace files, monorepos, and package manager configuration.
  • [ ] Search lockfiles for malicious Axios versions and plain-crypto-js.
    How to validate: Inspect package-lock.json, npm-shrinkwrap.json, yarn.lock, and pnpm-lock.yaml.
  • [ ] Inspect dependency trees for transitive exposure.
    How to validate: Use package manager dependency tree commands, SBOM tools, software composition analysis, or internal dependency inventory.
  • [ ] Review private registry, proxy, and artifact repository download logs.
    How to validate: Look for downloads of Axios 1.14.1, Axios 0.30.4, or plain-crypto-js.
  • [ ] Review container images and build layers.
    How to validate: Scan base images, app images, ephemeral builder images, and cached dependency layers.
  • [ ] Review developer workstation package caches.
    How to validate: Check npm, yarn, pnpm, and shared build caches; clear caches after evidence collection.
  • [ ] Document every affected repository, build pipeline, host, image, and deployed service.
    How to validate: Maintain an exposure register with owner, status, and remediation evidence.

Phase 3: Microsoft Sentinel Threat Intelligence Checklist

Use Microsoft Sentinel threat intelligence to convert the campaign IOCs into managed STIX objects that can drive analytics, hunting, and incident creation.

  • [ ] Confirm permissions and connectors.
    Details: Ensure the Threat Intelligence solution and relevant data connectors are enabled and telemetry is flowing.
  • [ ] Open the Sentinel threat intelligence management interface.
    Details: In the Defender portal, navigate to Threat intelligence > Intel management.
  • [ ] Create campaign-specific STIX indicators.
    Details: Add indicators for C2 domains, URLs, IP addresses, and file hashes listed in the IOC appendix.
  • [ ] Use consistent tags.
    Details: Suggested tags: Axios-NPM-Compromise, SupplyChain, UNC1069, WAVESHAPER-V2, NodeJS.
  • [ ] Set confidence, validity, source, and TLP.
    Details: Use values aligned with your threat intelligence policy and extend validity for high-value indicators where appropriate.
  • [ ] Create relationships.
    Details: Relate indicators to threat actor, malware, attack pattern, campaign, and affected identity objects where your TI model supports it.
  • [ ] Bulk import where possible.
    Details: Use CSV, STIX/TAXII, or approved TI platform workflows for multiple indicators. Note: IOCs are available under Threat Intelligence in the Unified Security Experience portal for organizations using Microsoft Sentinel in Defender.
  • [ ] Review indicator freshness.
    Details: Validate that analytics rules can match indicators within expected lookup and refresh behavior.

Phase 4: Sentinel Analytics Rule Checklist

Use the Microsoft Sentinel TI map… analytics rule templates to generate alerts and incidents when threat indicators match ingested telemetry.

  • [ ] IP indicators
    Checklist: Enable a relevant TI map IP rule for network, firewall, DNS, proxy, cloud activity, or endpoint telemetry sources available in your workspace.
  • [ ] Domain and URL indicators
    Checklist: Enable TI map rules that match DNS, proxy, Defender, and network logs against campaign domains and URLs.
  • [ ] File hash indicators
    Checklist: Enable file-hash TI map rules for endpoint telemetry such as Defender device file events.
  • [ ] Scheduling
    Checklist: Use the default schedule where appropriate, then tune frequency based on telemetry latency and SOC requirements.
  • [ ] Entity mapping
    Checklist: Confirm IP, URL, host, file hash, account, and process entity mappings are present and useful for investigation.
  • [ ] Incident generation
    Checklist: Enable incident creation and route incidents to the correct SOC queue. Utilize the TI Map Analytic Rule templates to create rules that detect the campaign IoCs in the organization. Convert specific Hunting Queries into custom detections or ARs in Sentinel.
  • [ ] Automation
    Checklist: Attach automation rules or playbooks for enrichment, owner notification, endpoint isolation requests, and ticket creation.
  • [ ] Validation
    Checklist: Review the SecurityAlert table and Sentinel incidents to verify rules are producing actionable results.

Phase 5: Detection Engineering and Hunting Checklist

Sample hunting queries

The following sample hunting queries were taken from the Microsoft Security Blog article Mitigating the Axios npm supply chain compromise and can be adapted for your environment and available telemetry. They cover

  • suspicious network connections
    • npm/node child process chains
    • file artifacts
    • Windows persistence indicators

Sample query: devices with suspicious network connections related to the compromise


DeviceNetworkEvents
| where RemoteUrl has_any (“sfrclak.com”) or RemoteIP in (“142.11.206.73″,”23.254.167.216”)
| where RemotePort == 8000 or InitiatingProcessFileName in~ (“node.exe”,”npm.exe”,”yarn.exe”,”pnpm.exe”,”node”,”npm”,”yarn”,”pnpm”)
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort

DeviceNetworkEvents

| where RemoteUrl has_any (“sfrclak.com”) or RemoteIP in (“142.11.206.73″,”23.254.167.216”)| where RemotePort == 8000 or InitiatingProcessFileName in~ (“node.exe”,”npm.exe”,”yarn.exe”,”pnpm.exe”,”node”,”npm”,”yarn”,”pnpm”)| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort

Sample query: suspicious process chains from npm or node execution


DeviceProcessEvents
| where InitiatingProcessFileName in~ (“node.exe”,”npm.exe”,”yarn.exe”,”pnpm.exe”,”node”,”npm”,”yarn”,”pnpm”)
| where FileName in~ (“cmd.exe”,”powershell.exe”,”curl.exe”,”bash”,”zsh”,”python”,”python3″,”wt.exe”)
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine

Sample query: file artifacts associated with Windows, macOS, and Linux payloads


DeviceFileEvents
| where FolderPath has_any (“%PROGRAMDATA%”,”/Library/Caches/com.apple.act.mond”,”/tmp”)
| where FileName in~ (“wt.exe”,”system.bat”,”ld.py”,”setup.js”)
| project Timestamp, DeviceName, ActionType, FolderPath, FileName, SHA256

Sample query: persistence and command execution indicators on Windows


DeviceRegistryEvents
| where RegistryKey has @”\\Software\\Microsoft\\Windows\\CurrentVersion\\Run”
| where RegistryValueName =~ “MicrosoftUpdate”
| project Timestamp, DeviceName, RegistryKey, RegistryValueName, RegistryValueData

Tune these sample queries to your specific tables, connector coverage, retention window, and field names. If you use Microsoft Sentinel with Defender XDR data, you may need to adapt the table names or add joins for broader coverage. If you use a different EDR solution, modify the queries above to adapt to the endpoint telemetry you are capturing in your SIEM.

  • [ ] NPM postinstall execution
    Hunt for: Package installation events where node, npm, yarn, or pnpm spawns shell interpreters or download utilities.
  • [ ] Windows execution
    Hunt for: node.exe spawning cmd.exe, powershell.exe, copied wt.exe, curl.exe, hidden windows, execution policy bypass, or payloads in %TEMP%.
  • [ ] Windows persistence
    Hunt for: %PROGRAMDATA%\system.bat and registry Run key value named MicrosoftUpdate under HKCU:\Software\Microsoft\Windows\CurrentVersion\Run.
  • [ ] macOS execution
    Hunt for: Downloads or execution from /Library/Caches/com.apple.act.mond, suspicious curl, bash, or zsh launched during package installation.
  • [ ] Linux execution
    Hunt for: Downloads or execution of /tmp/ld.py, Python backdoor execution, suspicious outbound traffic from developer or build systems.
  • [ ] Network activity
    Hunt for: Connections to known C2 infrastructure (IoCs related to campaign), port 8000, 60-second beaconing, Base64-encoded JSON beacons, and the User-Agent mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0).
  • [ ] Forensic cleanup attempts
    Hunt for: Deletion of setup.js, changes replacing package.json from package.md, or package metadata reverting after installation.
  • [ ] Credential exposure
    Hunt for: Access to environment variables, cloud credentials, npm tokens, SSH keys, signing keys, keychain material, or CI/CD secrets from affected systems.

Phase 6: Credential Rotation Checklist

If the malicious dependency executed on a host, assume secrets accessible to that host may be compromised.

  • [ ] NPM tokens
    Action: Revoke and reissue maintainer, automation, publish, and read tokens. Enforce least privilege and MFA.
  • [ ] CI/CD secrets
    Action: Rotate pipeline variables, deployment tokens, service connections, webhook secrets, and runner credentials.
  • [ ] Cloud credentials
    Action: Rotate access keys, service principals, workload identities, and deployment credentials used on affected hosts.
  • [ ] Source control credentials
    Action: Rotate personal access tokens, deploy keys, SSH keys, and GitHub/GitLab/ADO tokens exposed to affected systems.
  • [ ] Application secrets
    Action: Rotate database credentials, API keys, signing secrets, OAuth client secrets, and third-party service keys.
  • [ ] Secrets in local files
    Action: Identify plaintext secrets in .env, shell profiles, credential files, package manager config, and local key stores.
  • [ ] Audit usage
    Action: Review authentication logs for unusual use before and after rotation.

Phase 7: Recovery Checklist

  • [ ] Roll back Axios to a known-good approved version.
    Validation: Confirm lockfiles and deployed artifacts no longer reference malicious versions.
  • [ ] Remove plain-crypto-js from dependency trees unless explicitly business-approved and verified benign.
    Validation: Dependency tree and SBOM scans are clean.
  • [ ] Clear local, shared, and CI package caches.
    Validation: npm, yarn, pnpm, build cache, and artifact cache cleanup records exist.
  • [ ] Rebuild affected developer workstations and CI runners from known-good images when compromise is likely.
    Validation: Fresh images deployed and old runners decommissioned.
  • [ ] Rebuild application artifacts after dependency rollback.
    Validation: New builds must use pinned dependencies and trusted artifact sources.
  • [ ] Redeploy only after validation gates pass.
    Validation: Security scan, dependency review, and incident commander approval are complete.

Phase 8: Long-Term Hardening Checklist

  • [ ] Dependency pinning
    Implementation guidance: Require lockfiles and deterministic builds. Avoid unbounded semver ranges for production builds.
  • [ ] Private registry controls
    Implementation guidance: Use allowlists, quarantine newly published packages, and block known-bad package versions.
  • [ ] Auto-update governance
    Implementation guidance: Disable unsafe automatic upgrades for critical dependencies. Require review and staged rollout.
  • [ ] Package provenance
    Implementation guidance: Prefer packages with provenance metadata, signed artifacts, verified maintainers, and transparent release processes.
  • [ ] Build isolation
    Implementation guidance: Run builds in ephemeral, sandboxed environments with minimal host filesystem access.
  • [ ] Secret vaulting
    Implementation guidance: Remove plaintext secrets from developer machines and build environments; use managed identity and secure vaults.
  • [ ] Maintainer protection
    Implementation guidance: Require MFA, phishing-resistant authentication where possible, least-privilege package publishing, and emergency token revocation procedures.
  • [ ] Continuous monitoring
    Implementation guidance: Monitor package registry events, dependency drift, newly added postinstall scripts, and build-time process anomalies.
  • [ ] SBOM and SCA coverage
    Implementation guidance: Generate SBOMs for applications and images, store them with releases, and continuously scan for compromised package versions.

Rollback Plan

  1. If a remediation deployment fails, stop the deployment and keep the previous known-good production artifact running only if it is confirmed not to contain malicious Axios versions or plain-crypto-js.
  2. If the previous artifact is exposed, prioritize emergency rollback to an earlier clean build, hotfix build with pinned safe dependencies, or temporary service isolation.
  3. If credentials were rotated incorrectly, use break-glass procedures to restore service using newly issued credentials, not previously exposed secrets.
  4. If Sentinel analytics rules generate excessive noise, tune scope and source connectors, but do not remove campaign indicators until containment and hunting are complete.

Post-Checks

  • [ ] No source repository, lockfile, SBOM, artifact, image, or deployed workload references Axios 1.14.1, Axios 0.30.4, or malicious plain-crypto-js versions.
  • [ ] No active endpoint telemetry indicates WAVESHAPER.V2 payload paths, persistence artifacts, suspicious child processes, or known file hashes.
  • [ ] No DNS, proxy, firewall, endpoint, or cloud logs show active communication with known C2 infrastructure.
  • [ ] All credentials accessible to affected systems were rotated and suspicious authentication activity was reviewed.
  • [ ] Microsoft Sentinel TI objects and TI map analytics rules are active, producing useful incidents, and routed to the correct SOC workflow.
  • [ ] Affected developer machines, build runners, and caches have been rebuilt or remediated according to incident response decisions.
  • [ ] Lessons learned are documented and long-term hardening tasks are assigned with owners and due dates.

Appendix A: Baseline Indicators of Compromise

Validate indicators with your threat intelligence source of record before enforcement. Indicators can age quickly and should be managed with confidence, validity, source, and TLP metadata.

Network Indicators

IP Addresses

  • 142.11.206.73
    Type: IP address
    Notes: Reported C2 for WAVESHAPER.V2
  • 23.254.167.216
    Type: IP address
    Notes: Reported suspected UNC1069 infrastructure

Domains

  • sfrclak[.]com
    Type: Domain
    Notes: Reported C2 for WAVESHAPER.V2

URLs

  • http://sfrclak[.]com:8000
    Type: URL
    Notes: Reported C2 endpoint
  • http://sfrclak[.]com:8000/6202033
    Type: URL
    Notes: Reported payload/C2 path

File Indicators

SHA256 Indicators

  • e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09
    Type: SHA256
    Notes: SILKBELL setup.js JavaScript dropper
  • fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf
    Type: SHA256
    Notes: WAVESHAPER.V2 Linux Python RAT
  • 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a
    Type: SHA256
    Notes: WAVESHAPER.V2 macOS native binary
  • 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101
    Type: SHA256
    Notes: WAVESHAPER.V2 Windows Stage 1
  • ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c
    Type: SHA256
    Notes: Reported WAVESHAPER.V2-related hash
  • f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd
    Type: SHA256
    Notes: system.bat
  • 58401c195fe0a6204b42f5f90995ece5fab74ce7c69c67a24c61a057325af668
    Type: SHA256
    Notes: plain-crypto-js-4.2.1.tgz

Appendix B: Microsoft Sentinel Implementation Notes

  • Threat indicators can come from TI feeds, TI platforms, bulk flat-file import, or manual input. TI Feeds for MDTI are now available in Microsoft Sentinel for this campaign.
  • Sentinel analytics rules that use threat intelligence should use the TI map… format so indicators can map to ingested events.
  • Review required data sources for each TI map rule before enabling it.
  • Use entity mappings, so incidents contain usable IP, domain, URL, file, account, device, and process context.
  • Consider automation rules and Logic Apps playbooks for enrichment, notification, ticketing, and response orchestration.
  • Monitor active rules and generated alerts in Sentinel, including the SecurityAlert, AlertInfo and AlertEntity tables and incident queue.

Contacts

  • Incident Commander: Assign per incident
  • SOC Lead: Assign per incident
  • SOC Analysts/Engineer: assign hunting and detection activities (AR enablements, creation of custom detections etc.)
  • DevSecOps Lead: Assign per incident
  • Platform Engineering Lead: Assign per incident
  • Application Owner: Assign per impacted service

Source References

Defender for Cloud deployment in AWS/GCP – Agents, Resources, IAM and Cleanup options

A while back I had the incredible fortune to collaborate with Inbal Silis and Bojan Magusic on this blog post, summarizing the learnings we saw with customers that used Microsoft Defender for Cloud to improve the Security Posture of their workloads in different Clouds.
The purpose of this article is to provide organizations with a comprehensive understanding of all the agents and resources deployed as part of Defender for Server, Defender for Container, Defender for SQL in their AWS/GCP environment by Defender for Cloud. The article aims to guide organizations on the impact of Defender for Cloud on their environment and what they need to remove when switching Defender for Cloud plans on the security connector. Where possible this article should avoid duplicating information that is already available on Microsoft Learn and focus on providing information that is not publicly available or documented on Microsoft Learn.

Defender for Cloud deployment in AWS/GCP – Agents, Resources, IAM and Cleanup options

Happy reading!

Windows Events, how to collect them in Sentinel and which way is preferred to detect Incidents.

I started blogging again, but this time the article is on the Microsoft Tech Community platform. I’ve been working with Microsoft Sentinel for 3 years now, from its start as Azure Sentinel. The contents of this blog are the result of my experience delivering migrations to Sentinel from other SIEMs and green-field adoption projects where SOC teams learn and adopt Microsoft Sentinel as their SIEM. On several of these projects the three main ways of ingesting Windows Server OS logs for IaaS architectures is a recurring theme. Even in multi-cloud environments. This article outline the main 3 ways to ingest OS events, which ones are considered Security Events, and the gotchas when utilizing a Windows Event Collector.

https://techcommunity.microsoft.com/t5/fasttrack-for-azure/windows-events-how-to-collect-them-in-sentinel-and-which-way-is/ba-p/3997342

my Azure Security refences

If you’re an Azure Security Ninja learning about Sentinel (Azure cloud native SIEM) here’s a free Azure Sentinel Webminar.

https://onedrive.live.com/?authkey=%21AM3%5FMenNud9f%2DZc&cid=66C31D2DBF8E0F71&id=66C31D2DBF8E0F71%21314&parId=66C31D2DBF8E0F71%21257&o=OneUp

Here’s a video on Azure Sentinel from Azure Fridays: https://www.youtube.com/watch?v=oiWInLYvnUk

For those of you learning about the Kusto Querying Language here’s a good online free class: https://www.youtube.com/watch?v=EDCBLULjtCM

More on KQL (Kusto Querying Language) and its use in Azure Sentinel:


If you want a full list of all the webminars and the assets/files shared on these webminars, take a look here -> https://techcommunity.microsoft.com/t5/microsoft-security-and/security-community-webinars/ba-p/927888

If you wonder how to integrate App Gateway WAFv1 and ASC:

https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-integration-security-center

If you want to learn more about Logic Apps to use them in one of our Security Services, star here ->

https://docs.microsoft.com/en-us/azure/logic-apps/quickstart-create-first-logic-app-workflow

Azure Fridays Azure Security Center video:

Use of Logic Apps:

Enjoy!

OWASP API Top 10 Most Critical Security Risks in 2019

A lot of us have been waiting for OWASP to publish a new set of top 10. Now that APIs are key in every solution, OWASP published the Top 10 Most Critical API Security Risks! It is worth the time to read it through. You don’t want to be in the news for the wrong reasons.  #infosecurity #applicationsecurity 

https://owasp.org/www-project-api-security/

Java – Spring Security Framework and Azure AD

Yesterday I was wondering if Microsoft support middleware packages for Java to allow the typical resource provider actions in an access_token or id_tokens, similarly to what the OWIN NuGet packages do or the PassportJS libraries for NodeJS. These last two libraries act as middlewares intercepting the HTTP requests. They allow to, programmatically, parse the Authorization headers to extract Bearer tokens, validate the tokens, extract claims from the tokens etc, etc.

The libraries I had found so far, and that I was familiar with, were the MSAL set of libaries and the ADAL set of libraries. These are client side libraries, meant for applications acting or APIs acting as OAuth2 Clients (not as Resource Providers)

Microsoft does not maintain a Java middleware library similar to OWIN or Passport. The development team is using Spring and will use Azure Active Directory as the Identity Provider, they could use Spring Boot Starter for AAD: https://github.com/microsoft/azure-spring-boot/tree/master/azure-spring-boot-starters/azure-active-directory-spring-boot-starter

Spring Boot is a wrapper of Spring Framework libraries packaged with preconfigured components.

They can also work with AAD and Spring Security, but there aren’t many articles out there related to that framework and how to use it when AAD is the IdP providing JWT tokens except for this one:

Article and related links: https://azure.microsoft.com/en-us/blog/spring-security-azure-ad/

There is also this old blog post with some sample code(using spring framework security, however the example is for illustration purposes only, and uses an access_token issued for a SPA client application in order to request access to an API, which is not exaclty the case of the application we’re trying to modernize (multi-page JSP web application)

https://dev.to/azure/using-spring-security-with-azure-active-directory-mga

OAuth2/OIDC Libraries for Java that work with Microsoft IDPs

Microsoft identity providers work with two types of libraries:

  • Client libraries: Native clients (iOS, Android), JavaScript SPA applications,  and servers use client libraries to acquire access tokens for calling a resource such as Microsoft Graph or other APIs.
  • Server middleware libraries: Web apps use server middleware libraries for user sign-in. Web APIs use server middleware libraries to validate tokens that are sent by native clients or by other servers.

Microsoft developers produce and maintains two client Open Source libraries for Java that work with Microsoft identity providers => ADAL and MSAL

They support the industry standards OAuth2.0 and OpenID Connect 1.0

Client Libraries and Microsoft  IDP versions

IDP (Identity Provider) Client Library
AAD v1 ADAL4J
ADFS OAuth/OIDC ADAL4J
AAD v2 MSAL Java (also known as MSAL4J)
AAD B2C MSAL Java (also known as MSAL4J)

MSAL Reference: https://javadoc.io/doc/com.microsoft.azure/msal4j/latest/index.html

MSAL Java Wiki https://github.com/AzureAD/microsoft-authentication-library-for-java/wiki

MSAL Java Project Entry point in GitHub https://github.com/AzureAD/microsoft-authentication-library-for-java

MSAL Java sample applications https://github.com/AzureAD/microsoft-authentication-library-for-java/tree/dev/src/samples

ADAL is an older library, used to communicate with identity providers such as ADFS and older versions of AAD v1 token and authorize endpoints

ADAL Reference https://javadoc.io/doc/com.microsoft.azure/adal4j/latest/index.html

Project source code in GitHub https://github.com/AzureAD/azure-activedirectory-library-for-java

Sample Java application https://github.com/Azure-Samples/active-directory-java-webapp-openidconnect

There is also an oauth2-oidc-sdk for Java that contain the namespaces needed for token deserialization, token validation(s) and processing of claims, which is typically done server side, when the web app or api receives a bearer token in the HTTP(S) Security Authorization Header.

To my knowledge, this SDK is not maintained by Microsoft.

https://www.javadoc.io/doc/com.nimbusds/oauth2-oidc-sdk/latest/index.html

Note: Server side validation of the token, specifically, the decryption of the token digital signature and the comparison of the decrypted hash vs. the calculated hash is critical to ensure the token claims weren’t tampered in transit and that the IdP wasn’t spoofed. There are other token validations, but this one in particular guarantees the integrity of the information and the source of the token.

This needs a good POC!

Managing external identities with AAD B2C tenants – public docs

Azure AD B2C is one of the most fast growing Identity Providers in the world. When this type of tenant was created for social identities and digital citizens, the Microsoft Identity team didn’t anticipate its massive growth. Over 1 billion of users authenticate to their apps, and apps to apis, using this type of Azure directory or tenant. When privacy norms such as GDPR in the European Union and CCPA in California, USA, came about, the flexibility provided by custom policies; the white label customization of the html/css and the Identity Experience Framework, allowed solutions where the end users have more control of their data, including the ability to remove the personal data that applications collect from them (profile information, credentials, user attributes and permissions). Microsoft Graph also provides one of the first RESTful APIs that allow application developers to programatically perform CRUD operations on user accounts and principals associated to applications and services.

This month the Microsoft Identity team has published a number of public articles to guide developers on the automation steps with Azure AD B2C: