Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Bug] macOS broker prompts twice for Keychain access, Always Allow doesn't apply to both

Offen
  • Stimmt etwas nicht?
#955 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
macos, python
Bereich
authentication, security

Rechercherichtung

The report points to Common Core’s MSIDMacKeychainTokenCache.m and MSIDMacACLKeychainAccessor.m, and asks about PyMsalRuntime’s unsigned-client flow. Start by tracing how one broker response is written to the shared and non-shared Keychain items, then check whether the Python repository exposes that flow. Done means establishing a supported way to avoid duplicate authorization prompts while preserving the shared/non-shared credential boundary.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

public-client untriaged

Describe the bug

On macOS, one broker-backed MSAL operation can (frequently) display two consecutive Keychain password dialogs. Choosing Always Allow in the first dialog does not prevent the second dialog. After choosing Always Allow in both dialogs, later requests stop prompting until the interpreter identity or Keychain state changes.

I had copilot confirm that my app makes one msal.broker._signin_silently() call and that MSAL makes one native pymsalruntime.signin_silently() call. The dialogs therefore arise within one native broker operation rather than from duplicate application authentication. It feels wrong to have to type my password twice for a single operation.

To reproduce

Prerequisites:

  • macOS with Company Portal and broker support configured.
  • A public client registration configured for the macOS broker.
  • An account already available to the broker.
  • An ad-hoc-signed Python executable that is not already trusted by the relevant login-Keychain items.
import msal

CLIENT_ID = "<public-client-id>"
AUTHORITY = "https://login.microsoftonline.com/<tenant>"
SCOPES = ["<scope>"]

app = msal.PublicClientApplication(
    client_id=CLIENT_ID,
    authority=AUTHORITY,
    enable_broker_on_mac=True,
)

# With prompt omitted, the broker path first attempts one silent sign-in.
result = app.acquire_token_interactive(scopes=SCOPES)
print(result.get("error") or "Token acquired")

Run the script with the ad-hoc-signed interpreter. When its executable has not previously been authorized for the existing MSAL Keychain cache, two Keychain dialogs will appear during the single silent broker operation.

Expected behavior

A single broker operation should not require two indistinguishable Keychain authorization grants. Ideally, an unsigned runtime-like broker client would rely on broker-owned persistent caching and use only process-local application caching. If persistent application-side Keychain caching is required, the UX should avoid or clearly explain multiple independent grants without weakening the shared/non-shared credential boundary.

What you see instead

  1. macOS requests the login-Keychain password.
  2. Always Allow is selected.
  3. A second, apparently identical Keychain password dialog immediately appears.
  4. Always Allow is selected again.
  5. Subsequent runs remain silent for a period of time.

The MSAL Python version you are using

msal==1.38.0
pymsalruntime==0.20.6

MSAL Python 1.38.0 already contains the unsigned-app redirect URI change from #907.

Environment

  • macOS 26.6.2
  • Apple Silicon (arm64)
  • Company Portal 5.2606.0
  • CPython 3.11.12 installed by uv
  • Python signature: ad-hoc/linker-signed
  • TeamIdentifier=not set

Investigation

Non-PII native logging showed:

  • The runtime continuing through the unsigned-app runtime flow.
  • Shared Keychain-group operations failing with -34018 (errSecMissingEntitlement), as expected for an ad-hoc-signed Python executable without the shared Keychain entitlement.
  • A fallback to the ACL-based login-Keychain implementation.
  • Multiple successful reads and updates through the macOS ACL Keychain accessor during the one silent sign-in.

The Common Core implementation appears to explain why two grants are needed:

  • MSIDMacKeychainTokenCache.m stores two distinct generic-password items:
    • A shared blob containing refresh tokens and accounts.
    • A non-shared blob containing access tokens, ID tokens, app metadata, and account metadata.
  • Both use the service/ACL label Microsoft Credentials, but they have different Keychain primary keys and independent ACLs.
  • MSIDMacACLKeychainAccessor.m creates a trusted-application reference for the current executable and reads each item with SecItemCopyMatching.

This is consistent with the observed behavior: Always Allow updates authorization for one Keychain item, but the other item still needs a separate grant even though the dialogs look the same. A changed Python installation path or executable identity can require new grants.

Upstream question

For unsigned runtime-like clients using the macOS broker, can PyMsalRuntime/Common Core avoid writing the broker response to the legacy ACL-based login-Keychain token cache and instead rely on broker persistence plus an in-memory process cache?

If the local cache is required for account discovery or other semantics, is there another way to avoid two separate user authorization dialogs while retaining the intentional shared/non-shared security boundary?

No tenant IDs, client IDs, account identifiers, correlation IDs, or token material are included in this report.

Vorherrschende Sprache
Python
Sterne
971
Forks
223
Ø Merge
1 T. 32 Min.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus AzureAD/microsoft-authentication-library-for-python

Alle Issues in AzureAD/microsoft-authentication-library-for-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.