Stalwart redirecting me to my SSO Provider (Zitadel) and it shows me this error:
{"error":"invalid_request","error_description":"Errors.App.NotFound"}
Even when I correctly entered client id:
(An error occurred: Sorry, new users can only put one embedded media item in a post.)
Let me look up the SSO/OIDC configuration documentation for Stalwart and Zitadel.
Based on the screenshots described and the documentation, the issue is almost certainly a mismatch between the Client ID registered in Stalwart’s OAuth client list and what Zitadel is seeing, or - more commonly - a redirect URI mismatch or audience (aud) claim mismatch. Here is what to check:
There are two completely separate roles at play, and it helps to be clear which direction you are going:
Option A - Stalwart acts as the OIDC client, delegating authentication to Zitadel
This is configured via a Directory object of type Oidc (WebUI: Settings > Authentication > Directories). Stalwart validates tokens that mail clients present. It does not initiate browser redirects itself - the error you are seeing on Zitadel’s side is happening because of what Stalwart passes in the OAuth authorization request.
Option B - Stalwart acts as the OIDC provider, and you are using Zitadel as a social/external login for Stalwart’s own WebUI login
This is a different flow, handled through OAuth client registrations.
client_id not registered / mismatched in ZitadelThe Client ID you enter in Stalwart’s configuration must exactly match the Application Client ID you created in Zitadel. Even a trailing space or wrong case will cause this error.
The redirect URI that Stalwart sends to Zitadel must be exactly listed in Zitadel’s application allowed redirect URIs. A common mistake is missing a trailing slash or using http vs https. The Stalwart WebUI registers stalwart://auth as its redirect URI - you need to add that (and your domain’s callback URL, e.g. https://mail.example.com/auth) to Zitadel.
requireAudience mismatchIn the Stalwart OIDC Directory config, the requireAudience field defaults to "stalwart". This must match the audience/resource you configured in Zitadel for this application. Either set requireAudience in Stalwart to your Zitadel client ID, or configure Zitadel to include "stalwart" in the aud claim of issued tokens.
Zitadel distinguishes between Web, Native, and API application types. For the WebUI login flow, you need a Web application with the Authorization Code grant type and PKCE enabled. Make sure the application type matches what the flow expects.
Since the images are not all visible, could you share:
Relevant docs:
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
That Errors.App.NotFound is coming from Zitadel, not Stalwart: it means Zitadel has no OAuth application matching the client_id in the authorize request. So the thing to check is that the client_id in Stalwart’s OIDC directory config matches the Zitadel application’s client_id exactly (no stray whitespace, right project, app not deleted).
Also confirm the Zitadel app is a Web/OIDC application with Stalwart’s callback URL registered as a redirect URI, and that issuerUrl points at your Zitadel instance so discovery resolves the right endpoints. If you can re-post the Stalwart directory config (you hit the one-embed limit last time) and the authorize redirect URL with secrets redacted, I can compare the client_id directly. Docs: OpenID Connect | Stalwart .
Stalwart has two sides of OIDC support - one is Stalwart being an OIDC provider and the other is Stalwart being an OIDC consumer / client - Overview | Stalwart. You’re looking at provider configuration, not consumer.
You need https://yourdomain/account/Settings/x:OidcProvider to configure as a client.
Ah sorry, that’s the opposite link.
From https://yourdomain/account/Settings/x:Directory, add a directory ( Portal ), change to OpenID Connect, enter your issuer information.
We don’t have a client ID in our usage of it, since we’re proxying through another service that constructs the authorization request for us.
I’m not sure how you’d be able to get this to work otherwise, it’s a bit weird.
I don’t know eather. Stalwart promissed Zitadel support:
Yeah, weird. We’re using it against Zitadel, but like I mentioned, we’re using a custom proxy that rewrite the oauth authorization request.
could you share how you achieve this?
