JMAP principal list secrets (hash) in order to verify against hash(pwd)

Questions
1

Your question

In the rest api, you could get the argon2 hash out with /api/principal, and therefore verify password by hashing user pwd input and compare to hash. Now secret returns “****”, is it possible to get the hash out, or is there a verifycorrectpwd function or similar?

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

The password hash is intentionally masked and there is no “verify password” API endpoint in Stalwart’s JMAP API. Here is the situation:

The hash is permanently masked. When you read a principal (or account) via the JMAP API, the secret/password field is always returned as **** (MASKED_PASSWORD). This is hardcoded in the server – the raw Argon2 hash is never exposed through the API, by design. There is no verifyPassword or equivalent JMAP method.

What you can do instead to verify a user’s credentials:

The recommended approach for programmatic credential verification is to use OAuth 2.0. Stalwart supports the standard Authorization Code and Device Authorization flows. If you control a confidential (server-side) application, you can use the OAuth token endpoint at /auth/token with grant_type=client_credentials or drive the user through the authorization code flow – the server performs the password check internally and issues an access token only on success. A successful token response confirms the credentials are valid.

For simple scripting, you can also use HTTP Basic auth (Authorization: Basic base64(user:password)) against the management API endpoint – a 200 response confirms the credentials are correct.

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. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.

3

That’s by design now. The secret/hash is masked on the wire (every secret field returns **** before any role check), so the client can’t pull the hash and verify offline, and there’s no JMAP-level verifyPassword method. Password verification is meant to happen by actually authenticating: hit /auth/token with the credentials and check the response, or use IMAP/SMTP/JMAP LOGIN.

If the use case is “is this password correct for that user?”, an authenticate-and-discard against the OAuth endpoint is the supported approach.