[mvaneijken]

PR #71 gave the module unattended authentication — -AuthenticationType OAuth, the client-credentials grant, with either a client secret or a certificate. It was never wired into the canary.

Until now that code was covered only by unit tests that mock Invoke-RestMethod (Invoke-OAuth2Authentication.Tests.ps1, 18 Its; Get-OAuthClientCertificate.Tests.ps1, 14). A mock accepts any JWT. Whether Microsoft still accepts the RS256 assertion New-OAuthClientAssertion signs — x5t in the header, aud/iss/sub/jti/exp in the payload — could not be tested that way, and so was not tested at all. The same goes for the tenant around it: a certificate credential Entra rejects, a scope that resolves to nothing, a client holding no application role.

What this adds

A second job in .github/workflows/entra-canary.yml, sharing the tenant, the entra-canary environment and the alerting, and sharing nothing else. It opens no browser, so it fails independently of the sign-in canary and its alert never claims Microsoft changed a sign-in page.

Four scenarios, one per credential form the module documents — they are separate runs because supplying two credentials means only one is under test:

Scenario	Credential
OAuthClientSecret	-Credential holding the client id and secret
OAuthCertificateStore	-OAuthCertificateThumbprint, from CurrentUser\My
OAuthCertificateFile	-OAuthCertificatePath — what a container uses
OAuthCertificateObject	-OAuthCertificate, one the caller already holds

The tenant is shaped like a customer's

Per Omada's OAuth documentation, a real tenant holds two app registrations, and New-EntraCanaryConfiguration.ps1 now provisions the same two:

1. The resource — the stand-in for the OpenID Connect application Omada is configured with. Carries the Application ID URI, exposes the application role, sets requestedAccessTokenVersion to 2.
2. The OAuth client — a separate confidential registration holding the credentials, because Omada is explicit that the OIDC registration "cannot be used with client secret grants, i.e., one new application registration must be created per client application that connects to ES".

The claims asserted are the ones that documentation tells an administrator to verify: aud is the OIDC application, azp is the client. The app role is asserted too — without the grant Entra either refuses the token or, where the resource does not require assignment, issues a role-less one that authenticates nothing at Omada, and those two cases must not be confusable.

Omada's own side — the user whose Username is the client id, in Impersonation service users — is out of scope: the canary has no Omada environment, and the same loopback stand-in the sign-in canary uses serves the resource here.

Why the assertions are written the way they are

Every assertion is made against the token that actually arrived at the resource. Start-CanaryRelyingParty.ps1 now records it (ResourceBearer, ResourceHitCount) for that purpose, and never renders it: a failing canary's diagnostic becomes a public issue.

Two reasons, neither redundant:

1. The stand-in authorizes nothing. It answers 200 to any /api/* request, credential or not, because it is a loopback listener and not Omada. "The request succeeded" says nothing about what was presented.
2. It is the regression guard for [Bug]: A failed OAuth token request sends an empty bearer token, so the identity provider's error surfaces as a 401 from Omada #102. Until that was fixed, a failed token request fell through to Authorization: Bearer and the user saw an unexplained 401 from Omada. Invoke-OAuthTokenRequest now stops on error and New-OAuthTokenRequestError re-throws carrying the AADSTS code — which the canary's diagnostic reads straight out of the exception message. This keeps that fixed rather than assumed.

Credential expiry

Both a secret and a certificate expire. The job reads the certificate's notAfter from the PFX it already holds and the secret's expiry from a published secret — not from Graph, which would mean giving the runner directory credentials it has no other use for — and emits a warning annotation below 30 days, so rotation happens before a red run rather than because of one.

Rotation is a deliberate switch (-RotateServicePrincipalCredential) rather than something every run does: a secret's value can be read only at creation, so rotating without -GitHubRepository would invalidate the credential GitHub holds and hand the replacement to nobody.

Verification

Check	Result
./Build/build.ps1 -Task Build (incl. PSScriptAnalyzer)	passes
New E2E file with no secrets set	7 skipped — stays out of normal builds, which also exclude the E2E tag
Tests/Unit/CanaryRelyingParty.Tests.ps1	31 pass (2 new, covering the recorded bearer and the empty-bearer case)
JWT payload decoding	verified across all four base64url padding remainders, and returns null rather than throwing on malformed input
Bearer plumbing	a real Invoke-OmadaRestMethod request's Authorization header recorded by the stand-in and read back claim by claim
Workflow YAML and its embedded PowerShell	both parse
Full unit suite	979 pass, 11 fail — all 11 reproduce on an untouched main checkout (Export-OmadaCookieFile buffer test, Switch-ToManualLogin selector-fallback tests); no module source is touched by this branch

A local fake token endpoint turned out to be impossible: the module refuses a non-HTTPS -OAuthUri, deliberately, because a plain-HTTP one would send the client secret in clear text. That is correct and does not affect the canary, which uses the real endpoint via -EntraIdTenantId.

Not verified here, and it cannot be: the tenant half. New-EntraCanaryConfiguration.ps1 has to be run against the canary tenant with a Graph session before the new job can do anything but skip. Granting the application role needs AppRoleAssignment.ReadWrite.All on top of the existing scopes.

One thing noticed on the way, not changed here

• -Credential is not in Set-RequestParameter's exclusion list, so on the secret scenario the client secret is forwarded to Invoke-RestMethod as a NetworkCredential alongside the Bearer header. .NET only sends it on a 401 challenge, so nothing leaks today, but an endpoint that challenges would receive it. Also worth its own issue.

[mvaneijken]

/validate

[mvaneijken]

Correction to the original description, since it asserted something false about the module.

I justified the token assertions by describing behaviour that issue #102 had already removed — a failed token request falling through to \Authorization: Bearer . I read that off a stale branch; on \main, \Invoke-OAuthTokenRequest\ stops on error and \New-OAuthTokenRequestError\ re-throws carrying the identity provider's own error code.

The assertions themselves are unchanged and still correct: the loopback stand-in authorizes nothing and answers 200 to any request, so reading the header is what keeps #102 fixed rather than assumed. Commit 2f86099 corrects the comments, the documentation and the alert text, and the description above is updated.

[mvaneijken]

/validate

[mvaneijken]

/validate

[mvaneijken]

/validate