Microsoft Entra ID login fails: combined prompt values and invalid public-client token request
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 1.5k
- Forks
- 692
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 23
Description
Pre-submission Checks
- I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
- I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.
Describe the bug
The official ownCloud Desktop Client cannot complete an OpenID Connect Authorization Code + PKCE login against Microsoft Entra ID.
The problem is reproducible with Desktop 7.1.0 using the Windows system OIDC configuration and with Desktop 6.0.3 after starting with a fresh per-user configuration.
Two consecutive failures can be reproduced:
-
Although the configured system value is
Prompt=consent, the client sendsprompt=consent select_account. Microsoft Entra ID rejects this withAADSTS90023: Unsupported 'prompt' value. -
If the authorization URL is manually corrected to
prompt=consent, Entra authenticates the user and returns an authorization code to the loopback listener. The token request then sends the client ID only asAuthorization: Basic base64(<client-id>:); the form body contains noclient_id. Entra rejects it withAADSTS900144: The request body must contain the following parameter: 'client_id'.
The Entra application is configured as a public native/desktop client. A client secret cannot be kept confidential in a distributed desktop application.
Expected behavior
- Send exactly the configured prompt value, e.g.
prompt=consent, or omit it when empty. - Support a public native client using Authorization Code + PKCE with
token_endpoint_auth_method=none. - Include
client_idin the token request form body. - Do not require or send a client secret for a public desktop client.
- Complete login and retain a refresh token when
offline_accessis requested.
Steps to reproduce the issue
- Register a single-tenant application in Microsoft Entra ID.
- Add the Mobile and desktop applications loopback redirect URI
http://127.0.0.1. - Configure it as a public native client using Authorization Code + PKCE; do not create a client secret.
- With Desktop 7.1.0 configure the Windows system OIDC settings:
ClientId=<redacted>,Ports=48080,Scopes=openid offline_access email profile, andPrompt=consent. - Start the client and add the preconfigured account.
- Observe that the URL contains
prompt=consent select_accountand Entra returns AADSTS90023. - Start a fresh attempt and change only
prompt=consent%20select_accounttoprompt=consent. - Complete the Entra login. The callback reaches
http://127.0.0.1:48080. - Observe AADSTS900144 during the token exchange.
- Install Desktop 6.0.3, rename the configuration created by 7.1.0 so that 6.0.3 starts with a fresh per-user configuration, and connect to the same oCIS instance.
- Observe AADSTS90023 again.
Screenshots
Screenshots show AADSTS90023 with both Desktop 7.1.0 and Desktop 6.0.3. They can be provided if required.
Logs
Authorization request generated by the client:
https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
?response_type=code
&client_id=<client-id>
&redirect_uri=http://127.0.0.1:48080
&code_challenge=<redacted>
&code_challenge_method=S256
&scope=openid email profile
&prompt=consent select_account
&state=<redacted>
After manually changing the prompt to one value, the callback succeeds:
accepted client connection from QHostAddress("127.0.0.1")
GET /?code=<redacted>&state=<redacted>&session_state=<redacted> HTTP/1.1
Token request:
POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
Authorization: Basic base64(<client-id>:)
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=<redacted>
&redirect_uri=http://127.0.0.1:48080
&code_verifier=<redacted>
&scope=openid%20email%20profile
Response:
{
"error": "invalid_request",
"error_description": "AADSTS900144: The request body must contain the following parameter: 'client_id'."
}
Client version number
Reproduced with two official Windows x64 releases:
ownCloud Desktop 7.1.0.19041
ownCloud Desktop 6.0.3.18040
Libraries for 6.0.3: Qt 6.8.3, OpenSSL 3.4.3
Windows 11 x64 (10.0.26200)
Installation: official Windows x64 MSI
Installation path: C:\Program Files\ownCloud
The 6.0.3 test used a fresh per-user configuration after renaming the configuration file written by 7.1.0.
Desktop environment (Linux only)
No response
Client package version and origin (Linux only)
No response
Installation path (Windows only)
C:\Program Files\ownCloud
Server information
ownCloud Infinite Scale (oCIS) 8.0.0
Deployment: Docker Compose on Ubuntu 24.04 LTS
External identity provider: Microsoft Entra ID, single tenant
Storage backend: S3-compatible object storage
Public URL: https://cloud.example.org
Browser login to the oCIS Web UI works. WebFinger/discovery directs the Desktop Client to the tenant-specific Microsoft issuer. The failure occurs in the Desktop Client's direct communication with Microsoft, not in the oCIS reverse proxy.
Additional context
Related issue: #11472
That issue documented prompt=select_account consent and was closed for the Desktop 6.0 milestone. However, the invalid combined prompt is still reproducible with Desktop 6.0.3 and 7.1.0. URL-encoding the space does not make two prompt values valid for Microsoft Entra ID.
The current client implementation also appears to support only client_secret_basic and client_secret_post at the token endpoint. A public native application needs support for none, with client_id in the form body and no client secret.
Embedding an Entra application secret in the registry or deploying it to every managed workstation is not an acceptable production workaround.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Desktop Client's OIDC authorization request and token exchange using the URLs and logs in this issue. Inspect how the configured prompt and token endpoint authentication method are handled. Done means a public native client can use exactly one prompt value, send client_id in the token form without a secret, and complete the PKCE login with a refresh token.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- authentication, desktop, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100