Not possible to configure client_id for an external OIDC directory

[quagsirus]

Issue Description

It's not possible to customise the client_id used with an external OIDC directory, breaking compatibility with many providers since some randomly generate a client ID for you to pass to the application, and don't allow you to input a custom one.

Expected Behavior

Stalwart should accept a custom OIDC client ID when configuring a directory (in this config object)

Stalwart should use that client ID when redirecting users to sign in via the OIDC provider e.g.

https://<oidc_issuer>/authorize?response_type=code&client_id=<**CUSTOM_CLIENT_ID**>&redirect_uri=...

Actual Behavior

Stalwart uses stalwart-webui as the client ID e.g.

https://<oidc_issuer>/authorize?response_type=code&client_id=stalwart-webui&redirect_uri=...

There is no way to change it.

Reproduction Steps

1. Configure an OIDC directory in Stalwart (Pocket ID is easy to setup if you don't have access to one)
2. Set that directory as the default auth provider in Stalwart
3. Log out
4. Attempt to log in with an email
5. Observe that you are redirected to the OIDC provider with the client ID of stalwart-webui

Relevant Log Output

No response

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

OIDC

Additional Context

No response

I acknowledge that:

• I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
• I have searched the Stalwart repository (both open and closed Discussions and Issues) and confirm this is not a duplicate.
• I have set the logging level to trace and included relevant log output if applicable.
• I agree to follow the project's Code of Conduct.

[quagsirus]

Separate but related - Stalwart operates as a public client - is it possible to work as a private client and accept a client secret in configuration?

[mdecimus]

Does your OIDC support anonymous dynamic client registration? If not I suggest you find a new IdP as you won't be able to use PACC once Apple and other mail clients implement it.

[banksy-git]

I think these are different types/classes of OIDC client.

Mail clients are many and distributed so anonymous DCR makes sense there.

The server though is a managed deployment with a known operator so I think a confidential client and stable identity to which policy can be easily attached is more suitable than anonymous DCR.

So while I can see the case for DCR in the client ecosystem (e.g. PACC), I don’t think that necessarily implies the server itself should require anonymous DCR as its only integration model.