M365 auth without being prompted with URL

[alspires]

Hi,

I am trying to set up a CI/CD configuration for a Teams app I've been working on, and I want to be able to validate the app package in the pipeline by using atk validate --package-file appPackage.zip. The catch is that this command only works when I'm logged in to a m365 account (it doesn't work if I use atk auth login azure to log in), but when I try logging in to m365, it prompts me with an URL to confirm the credentials, which can't be done when inside the pipelines.

I've looked everywhere for an answer and it seems to me that this is not possible. The documentation doesn't say anything about this specificaly and when I run atk auth login m365 --help these are the only options I get:

Usage: atk auth login m365 [options]

Log in to Microsoft 365 account.

Options:
  --tenant          Authenticate with a specific Microsoft Entra tenant. Default value: "".

Global Options:
  --version -v      Display Microsoft 365 Agents Toolkit CLI version.
  --help -h         Show Microsoft 365 Agents Toolkit CLI help.
  --interactive -i  Run the command in interactive mode. Default value: true.
  --debug           Print debug information. Default value: false.
  --verbose         Print diagnostic information. Default value: false.
  --telemetry       Whether to enable telemetry. Default value: true.


For more information about the Microsoft 365 Agents Toolkit: https://aka.ms/teamsfx-toolkit-cli.

Can anyone confirm if that's the case and if I have any other option, please? If it is not possible I'll just leave it for now.

Thanks in advance.

[VikrantSingh01]

This is a common pain point when integrating the ATK CLI into CI/CD pipelines. The atk auth login m365 command uses an interactive browser-based or device code flow by default, which does not work in headless CI/CD environments. Here are your options.

Option 1: Use Azure Service Principal Authentication

The officially documented approach for CI/CD pipelines is to authenticate using atk auth login azure with a service principal, rather than atk auth login m365. This supports non-interactive authentication:

Secret-based:

npx atk auth login azure \
  --username $AZURE_SERVICE_PRINCIPAL_CLIENT_ID \
  --service-principal true \
  --tenant $AZURE_TENANT_ID \
  --password $AZURE_SERVICE_PRINCIPAL_CLIENT_SECRET \
  --interactive false

Certificate-based:

npx atk auth login azure \
  --username $AZURE_SERVICE_PRINCIPAL_CLIENT_ID \
  --service-principal true \
  --tenant $AZURE_TENANT_ID \
  --password cert.pem \
  --interactive false

This is documented in the CI/CD templates guide.

Important caveat: Service principal auth works for Azure-scoped operations (atk deploy, atk package, etc.), but it does not work for M365-specific operations that require an M365 account login. This is a known limitation.

Option 2: Validate Without M365 Authentication

For your specific use case (atk validate --package-file appPackage.zip), you may not actually need M365 authentication depending on which validation method you use.

The atk validate command supports two validation approaches:

1. Schema validation (--manifest-file): Validates your manifest.json against the Teams app manifest JSON schema. This is a local operation and should not require M365 login.
2. Validation rules (--package-file with --validate-method validation-rules): Applies additional validation rules that may require authentication.

For CI/CD, try running schema validation first:

npx atk validate --manifest-file ./appPackage/manifest.json --interactive false

If you need environment variable substitution, use the --env-file parameter:

npx atk validate --manifest-file ./appPackage/manifest.json \
  --env-file ./.env.production \
  --interactive false

Option 3: Offline Schema Validation (No ATK CLI Required)

If your goal is purely to validate the manifest structure as part of CI/CD quality gates, you can skip the ATK CLI entirely and validate your manifest.json directly against Microsoft's published JSON schema. The official schema is maintained at OfficeDev/microsoft-teams-app-schema.

For example, using ajv-cli in a Node.js pipeline:

npm install -g ajv-cli ajv-formats

# Download the schema (or pin it in your repo)
curl -o teams-schema.json \
  https://raw.githubusercontent.com/OfficeDev/microsoft-teams-app-schema/main/MicrosoftTeams.schema.json

# Unzip your app package and validate
unzip -o appPackage.zip -d appPackage_extracted
ajv validate -s teams-schema.json -d appPackage_extracted/manifest.json --all-errors

This runs entirely offline with no authentication and is well-suited for fast CI checks.

Summary / Recommendation

For your CI/CD pipeline doing atk validate --package-file appPackage.zip:

Approach	Auth Required?	Complexity
atk validate --manifest-file (schema only)	No	Low
Offline JSON schema validation (ajv etc.)	No	Low
atk auth login azure + service principal	Azure only	Medium

I would recommend starting with Option 2 or Option 3 if your primary goal is manifest/package validation in CI/CD. These do not require any M365 authentication. If you need deeper validation rules that require an authenticated session, Option 1 with service principal is the officially supported CI/CD path, though it is limited to Azure-scoped operations today.

References

• CI/CD Templates for Teams Apps
• Agents Toolkit CLI Reference
• Teams App Manifest JSON Schema (GitHub)

[abo1787]

So what if we do need to do m365 operations (I need to run the provision command and every time I do it is noting I need to login to the m365 endpoint).

It seems that AI is offering a solution of setting these environment variables and getting around it, I'm guessing that doesn't work and m365 simply requires an interactive auth? If not is there intentions for it to do this, or is this one of those things that will never work?

AI recommendation (copilot if it matters) - Set these in the ENV variables on the pipeline.
M365_ACCOUNT_NAME = XXXXX
M365_ACCOUNT_PASSWORD = XXXXXX
M365_TENANT_ID = XXXXX
CI_ENABLED = true

Run "npx atk provision" (should just work).

Currently using a service principal in the pipeline with client id and secret. Azure auth working properly.