OpenID Connect authentication failed AADSTS7000215

[Mike-E-angelo]

Hi Team Seq:

After month of working perfectly, the container not resetting I am now getting the following error when attempting to log into my Seq instance via Entra ID:

OpenID Connect authentication failed
AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '<appid>'. Trace ID:  <trace> Correlation <correlation> Timestamp: 2026-03-03 18:34:19Z

What would cause this? I have done zero operations to the server and I cannot log into my machine anymore. :(

Thank you for any assistance you can provide.

[mloskot]

I'd first check if the client secret has not expired.

[Mike-E-angelo]

Ah, sorry for the lack of detail. I had to rebuild my Seq instance in January due to Azure Storage file corruption (yet again 😞), so the client secret expires 1/13/2027.

[nblumhardt]

Hi @Mike-E-angelo, sorry to hear about the difficulties.

It's very unusual to keep hitting storage corruptions on ACI with Premium Files. I do recall there were some gotchas with ensuring a Premium Files volume is actually mounted/usable under the Premium tier, so it might be worth digging around in that area (though I can't pinpoint any specifics, sorry).

The OIDC secret issue isn't a known one; I am stuck wondering whether it might be related to the corruption issue 🤔

Do you have a recovery key stored for the instance? If so, there's an example of restoring the OIDC client secret in the docs:

https://datalust.co/docs/recovery-keys

But, for Entra ID the setting name is EntraIdClientKey.

If you don't have a recovery key, you can use init scripts to get back in:

https://datalust.co/docs/recovering-from-broken-authentication-settings

HTH!

[Mike-E-angelo]

Hi @nblumhardt thank you for your reply, it is appreciated. Indeed, I am not sure what is happening, but it seems I need to flatten my installation once a year, and it is most disruptive and resource-intensive, taking at least a day to get everything working as expected.

In this case, I was lucky to have a backup of the VM with the login still intact in the browser's cookie/cache, and I was able to restore and reestablish my login, then quickly set it to user/pass. This is, unfortunately, the latest in a long line of issues with Seq, and it seems I spend more time and effort administering it than using it. 😞

Incidentally, for your awareness, the browser in the backed-up VM initially displayed the error above after login, but after a second let me log in anyway, and I was able to access the interface. 🤔 That might be a scenario to test to ensure there's not a security issue somewhere.

As there is still no managed product as requested so long ago, I will be moving over to Sentry as that supports structured logging now. I still use Seq for local development, but in deployed scenarios, it has proven way too costly in terms of resources, time, and money. For reference, I am paying roughly $60/mo to host Seq when I can easily fit existing functionality in Sentry (not as nice an experience, however) for free.

It sucks to say goodbye to Seq for deployments, but if you ever land on a managed plan, I will gladly switch back. 🙏

[nblumhardt]

Hey @Mike-E-angelo! Thanks for the feedback; it sounds like an entirely reasonable decision, we really specialize in self-hosting so if that's a mismatch it's likely there are other related things that won't line up for your use case. Good luck with the switch, if there's anything we can do to help you get data across, just let us know :-)