Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#955 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Calme
Stack technique
macos, python
Domaine
authentication, security

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
971
Forks
223
Merge moyen
1 j 32 min
PR mergées (30 j)
1

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de AzureAD/microsoft-authentication-library-for-python

Toutes les issues de AzureAD/microsoft-authentication-library-for-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.