Conversation
Currently the test app sends both PoP parameters (see placeholder_auth_scheme definition) and also passes req_cnf and token type. There parameters are not compatible. If application passes PoP parameters, then MSAL (or the broker) owns the key and does the signing of the SHR. If application passes req_cnf, then application owns the key and creates and signs the SHR, so in this case it should not pass PoP parameters. The main flow is the first one - application passes only PoP parameters and either MSAL or the broker owns the key and generates the SHR.
There was a problem hiding this comment.
Pull request overview
This PR updates the MSAL Python console tester’s PoP interactive flow to avoid sending incompatible PoP request inputs simultaneously (PoP auth scheme parameters vs. req_cnf/token type), aligning the sample with the intended “MSAL/broker owns the key and generates the SHR” model.
Changes:
- Removes the hardcoded PoP
datapayload (includingreq_cnf) previously passed to the interactive PoP acquisition flow. - Updates
_acquire_pop_token_interactive()to call_acquire_token_interactive()without PoPdata.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| assert isinstance(app, msal.PublicClientApplication) | ||
| POP_SCOPE = ['6256c85f-0aad-4d50-b960-e6e9b21efe35/.default'] # KAP 1P Server App Scope, obtained from https://github.com/Azure/azure-cli-extensions/pull/4468/files#diff-a47efa3186c7eb4f1176e07d0b858ead0bf4a58bfd51e448ee3607a5b4ef47f6R116 | ||
| result = _acquire_token_interactive(app, scopes=POP_SCOPE, data=_POP_DATA) | ||
| result = _acquire_token_interactive(app, scopes=POP_SCOPE) |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR updates the MSAL Python console tester’s PoP acquisition flow to avoid sending mutually exclusive PoP request parameters, aligning the sample with the intended “MSAL/broker owns the key” PoP flow.
Changes:
- Removed the sample
_POP_DATApayload that includedreq_cnf,token_type, andkey_id. - Updated the PoP interactive helper to call the generic interactive acquisition without the incompatible payload.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| POP_SCOPE = ['6256c85f-0aad-4d50-b960-e6e9b21efe35/.default'] # KAP 1P Server App Scope, obtained from https://github.com/Azure/azure-cli-extensions/pull/4468/files#diff-a47efa3186c7eb4f1176e07d0b858ead0bf4a58bfd51e448ee3607a5b4ef47f6R116 | ||
| result = _acquire_token_interactive(app, scopes=POP_SCOPE, data=_POP_DATA) | ||
| print_json(result) | ||
| result = _acquire_token_interactive(app, scopes=POP_SCOPE) | ||
| if result.get("token_type") != "pop": | ||
| logging.error("Unable to acquire a pop token") |
| """Acquire a POP token interactively - This typically only works with Azure CLI""" | ||
| assert isinstance(app, msal.PublicClientApplication) | ||
| POP_SCOPE = ['6256c85f-0aad-4d50-b960-e6e9b21efe35/.default'] # KAP 1P Server App Scope, obtained from https://github.com/Azure/azure-cli-extensions/pull/4468/files#diff-a47efa3186c7eb4f1176e07d0b858ead0bf4a58bfd51e448ee3607a5b4ef47f6R116 | ||
| result = _acquire_token_interactive(app, scopes=POP_SCOPE, data=_POP_DATA) |
There was a problem hiding this comment.
If you removed _POP_DATA, can you leave some comments/instructions on how to construct POP parameters?
Also, can you validate if the parameters are good in this test?
microsoft-authentication-library-for-python/tests/broker-test.py
Lines 90 to 91 in 2de45ae
Currently the console app sends both PoP parameters (see placeholder_auth_scheme definition) and also passes req_cnf and token type. There parameters are not compatible. If application passes PoP parameters, then MSAL (or the broker) owns the key and does the signing of the SHR. If application passes req_cnf, then application owns the key and creates and signs the SHR, so in this case it should not pass PoP parameters.
The main flow is the first one - application passes only PoP parameters and either MSAL or the broker owns the key and generates the SHR.