| MSALPYTHON(1) | MSAL Python | MSALPYTHON(1) |
msalpython - MSAL Python Documentation
You can find high level conceptual documentations in the project README.
There are many different application scenarios. MSAL Python supports some of them. The following diagram serves as a map. Locate your application scenario on the map. If the corresponding icon is clickable, it will bring you to an MSAL Python sample for that scenario.
The following section is the API Reference of MSAL Python. The API Reference is like a dictionary. You read this API section when and only when:
NOTE:
Other modules in the source code are all considered as internal helpers, which could change at anytime in the future, without prior notice.
MSAL proposes a clean separation between public client applications and confidential client applications.
They are implemented as two separated classes, with different methods for different authentication scenarios.
For PublicClientApplication, you simply use None here. For ConfidentialClientApplication, it can be a string containing client secret, or an X509 certificate container in this form:
{
"private_key": "...-----BEGIN PRIVATE KEY-----...",
"thumbprint": "A1B2C3D4E5F6...",
"public_certificate": "...-----BEGIN CERTIFICATE-----... (Optional. See below.)",
"passphrase": "Passphrase if the private_key is encrypted (Optional. Added in version 1.6.0)",
}
Added in version 0.5.0: public_certificate (optional) is public key certificate which will be sent through 'x5c' JWT header only for subject name and issuer authentication to support cert auto rolls.
Per specs, "the certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one." However, your certificate's issuer may use a different order. So, if your attempt ends up with an error AADSTS700027 - "The provided signature value did not match the expected signature value", you may try use only the leaf cert (in PEM/str format) instead.
Added in version 1.13.0: It can also be a completely pre-signed assertion that you've assembled yourself. Simply pass a container containing only the key "client_assertion", like this:
{
"client_assertion": "...a JWT with claims aud, exp, iss, jti, nbf, and sub..."
}
Added in version 0.5.0: It is a dictionary of extra claims that would be signed by by this ConfidentialClientApplication 's private key. For example, you can use {"client_ip": "x.x.x.x"}. You may also override any of the following default claims:
{
"aud": the_token_endpoint,
"iss": self.client_id,
"sub": same_as_issuer,
"exp": now + 10_min,
"iat": now,
"jti": a_random_uuid
}
A URL that identifies a token authority. It should be of the format https://login.microsoftonline.com/your_tenant By default, we will use https://login.microsoftonline.com/common
Changed in version 1.17: you can also use predefined constant and a builder like this:
from msal.authority import (
AuthorityBuilder,
AZURE_US_GOVERNMENT, AZURE_CHINA, AZURE_PUBLIC) my_authority = AuthorityBuilder(AZURE_PUBLIC, "contoso.onmicrosoft.com") # Now you get an equivalent of # "https://login.microsoftonline.com/contoso.onmicrosoft.com" # You can feed such an authority to msal's ClientApplication from msal import PublicClientApplication app = PublicClientApplication("my_client_id", authority=my_authority, ...)
(optional) Allows configuration of one or more client capabilities, e.g. ["CP1"].
Client capability is meant to inform the Microsoft identity platform (STS) what this client is capable for, so STS can decide to turn on certain features. For example, if client is capable to handle claims challenge, STS can then issue CAE access tokens to resources knowing when the resource emits claims challenge the client will be capable to handle.
Implementation details: Client capability is implemented using "claims" parameter on the wire, for now. MSAL will combine them into claims parameter which you will later provide via one of the acquire-token request.
AAD provides regional endpoints for apps to opt in to keep their traffic remain inside that region.
As of 2021 May, regional service is only available for acquire_token_for_client() sent by any of the following scenarios:
This parameter defaults to None, which means region behavior remains off.
App developer can opt in to a regional endpoint, by provide its region name, such as "westus", "eastus2". You can find a full list of regions by running az account list-locations -o table, or referencing to this doc.
An app running inside Azure Functions and Azure VM can use a special keyword ClientApplication.ATTEMPT_REGION_DISCOVERY to auto-detect region.
NOTE:
You should consider opting in/out region behavior on-demand, by loading azure_region=None or azure_region="westus" or azure_region=True (which means opt-in and auto-detect) from your per-deployment configuration, and then do app = ConfidentialClientApplication(..., azure_region=azure_region).
Alternatively, you can configure a short timeout, or provide a custom http_client which has a short timeout. That way, the latency would be under your control, but still less performant than opting out of region feature.
New in version 1.12.0.
MSAL has long been caching tokens in the token_cache. Recently, MSAL also introduced a concept of http_cache, by automatically caching some finite amount of non-token http responses, so that long-lived PublicClientApplication and ConfidentialClientApplication would be more performant and responsive in some situations.
This http_cache parameter accepts any dict-like object. If not provided, MSAL will use an in-memory dict.
If your app is a command-line app (CLI), you would want to persist your http_cache across different CLI runs. The following recipe shows a way to do so:
# Just add the following lines at the beginning of your CLI script import sys, atexit, pickle http_cache_filename = sys.argv[0] + ".http_cache" try:
with open(http_cache_filename, "rb") as f:
persisted_http_cache = pickle.load(f) # Take a snapshot except (
FileNotFoundError, # Or IOError in Python 2
pickle.UnpicklingError, # A corrupted http cache file
):
persisted_http_cache = {} # Recover by starting afresh atexit.register(lambda: pickle.dump(
# When exit, flush it back to the file.
# It may occasionally overwrite another process's concurrent write,
# but that is fine. Subsequent runs will reach eventual consistency.
persisted_http_cache, open(http_cache_file, "wb"))) # And then you can implement your app as you normally would app = msal.PublicClientApplication(
"your_client_id",
...,
http_cache=persisted_http_cache, # Utilize persisted_http_cache
...,
#token_cache=..., # You may combine the old token_cache trick
# Please refer to token_cache recipe at
# https://msal-python.readthedocs.io/en/latest/#msal.SerializableTokenCache
) app.acquire_token_interactive(["your", "scope"], ...)
Content inside http_cache are cheap to obtain. There is no need to share them among different apps.
Content inside http_cache will contain no tokens nor Personally Identifiable Information (PII). Encryption is unnecessary.
New in version 1.16.0.
Historically, MSAL would connect to a central endpoint located at https://login.microsoftonline.com to acquire some metadata, especially when using an unfamiliar authority. This behavior is known as Instance Discovery.
This parameter defaults to None, which enables the Instance Discovery.
If you know some authorities which you allow MSAL to operate with as-is, without involving any Instance Discovery, the recommended pattern is:
known_authorities = frozenset([ # Treat your known authorities as const
"https://contoso.com/adfs", "https://login.azs/foo"]) ... authority = "https://contoso.com/adfs" # Assuming your app will use this app1 = PublicClientApplication(
"client_id",
authority=authority,
# Conditionally disable Instance Discovery for known authorities
instance_discovery=authority not in known_authorities,
)
If you do not know some authorities beforehand, yet still want MSAL to accept any authority that you will provide, you can use a False to unconditionally disable Instance Discovery.
New in version 1.19.0.
A broker is a component installed on your device. Broker implicitly gives your device an identity. By using a broker, your device becomes a factor that can satisfy MFA (Multi-factor authentication). This factor would become mandatory if a tenant's admin enables a corresponding Conditional Access (CA) policy. The broker's presence allows Microsoft identity platform to have higher confidence that the tokens are being issued to your device, and that is more secure.
An additional benefit of broker is, it runs as a long-lived process with your device's OS, and maintains its own cache, so that your broker-enabled apps (even a CLI) could automatically SSO from a previously established signed-in session.
This parameter defaults to None, which means MSAL will not utilize a broker. If this parameter is set to True, MSAL will use the broker whenever possible, and automatically fall back to non-broker behavior. That also means your app does not need to enable broker conditionally, you can always set allow_broker to True, as long as your app meets the following prerequisite:
New in version 1.20.0.
It automatically provides nonce protection.
Scopes requested to access a protected API (a resource).
Most of the time, you can leave it empty.
If you requested user consent for multiple resources, here you will need to provide a subset of what you required in initiate_auth_code_flow().
OAuth2 was designed mostly for singleton services, where tokens are always meant for the same resource and the only changes are in the scopes. In AAD, tokens can be issued for multiple 3rd party resources. You can ask authorization code for multiple resources, but when you redeem it, the token is for only one intended recipient, called audience. So the developer need to specify a scope so that we can restrict the token to be issued for the corresponding audience.
def authorize(): # A controller in a web app
try:
result = msal_app.acquire_token_by_auth_code_flow(
session.get("flow", {}), request.args)
if "error" in result:
return render_template("error.html", result)
use(result) # Token(s) are available in result and cache
except ValueError: # Usually caused by CSRF
pass # Simply ignore them
return redirect(url_for("index"))
(Required) Scopes requested to access a protected API (a resource).
If you requested user consent for multiple resources, here you will typically want to provide a subset of what you required in AuthCode.
OAuth2 was designed mostly for singleton services, where tokens are always meant for the same resource and the only changes are in the scopes. In AAD, tokens can be issued for multiple 3rd party resources. You can ask authorization code for multiple resources, but when you redeem it, the token is for only one intended recipient, called audience. So the developer need to specify a scope so that we can restrict the token to be issued for the corresponding audience.
You use this method only when you have old RTs from elsewhere, and now you want to migrate them into MSAL. Calling this method results in new tokens automatically storing into MSAL.
You do NOT need to use this method if you are already using MSAL. MSAL maintains RT automatically inside its token cache, and an access token can be retrieved when you call acquire_token_silent().
See this page for constraints of Username Password Flow. https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Username-Password-Authentication
Prerequisite: In Azure Portal, configure the Redirect URI of your "Mobile and Desktop application" as http://localhost. If you opts in to use broker during PublicClientApplication creation, your app also need this Redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/YOUR_CLIENT_ID
Can be one of "consumers" or "organizations" or your tenant domain "contoso.com". If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience. More information on possible values here and here.
OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated. If the elapsed time is greater than this value, Microsoft identity platform will actively re-authenticate the End-User.
MSAL Python will also automatically validate the auth_time in ID token.
New in version 1.15.
OPTIONAL. If your app is a GUI app running on modern Windows system, and your app opts in to use broker, you are recommended to also provide its window handle, so that the sign in UI window will properly pop up on top of your window.
New in version 1.20.0.
A callback with the form of lambda ui="xyz", **kwargs: print("A {} will be launched".format(ui)), where ui will be either "browser" or "broker". You can use it to inform your end user to expect a pop-up window.
New in version 1.20.0.
It is done either by finding a valid access token from cache, or by finding a valid refresh token from cache and then automatically use it to redeem a new access token.
This method will combine the cache empty and refresh error into one return value, None. If your app does not care about the exact token refresh error during token cache look-up, then this method is easier and recommended.
Internally, this method calls acquire_token_silent_with_error().
It is done either by finding a valid access token from cache, or by finding a valid refresh token from cache and then automatically use it to redeem a new access token.
This method will differentiate cache empty from token refresh error. If your app cares the exact token refresh error during token cache look-up, then this method is suitable. Otherwise, the other method acquire_token_silent() is recommended.
An account can later be used in acquire_token_silent() to find its tokens.
Default value is "code" for an OAuth2 Authorization Code grant.
You could use other content such as "id_token" or "token", which would trigger an Implicit Grant, but that is not recommended.
Can be one of "consumers" or "organizations" or your tenant domain "contoso.com". If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience. More information on possible values here and here.
Later when the response reaches your redirect_uri, you can use acquire_token_by_auth_code_flow() to complete the authentication/authorization.
Can be one of "consumers" or "organizations" or your tenant domain "contoso.com". If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience. More information on possible values here and here.
OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated. If the elapsed time is greater than this value, Microsoft identity platform will actively re-authenticate the End-User.
MSAL Python will also automatically validate the auth_time in ID token.
New in version 1.15.
{
"auth_uri": "https://...", // Guide user to visit this
"state": "...", // You may choose to verify it by yourself,
// or just let acquire_token_by_auth_code_flow()
// do that for you.
"...": "...", // Everything else are reserved and internal
}
The caller is expected to:
For PublicClientApplication, you simply use None here. For ConfidentialClientApplication, it can be a string containing client secret, or an X509 certificate container in this form:
{
"private_key": "...-----BEGIN PRIVATE KEY-----...",
"thumbprint": "A1B2C3D4E5F6...",
"public_certificate": "...-----BEGIN CERTIFICATE-----... (Optional. See below.)",
"passphrase": "Passphrase if the private_key is encrypted (Optional. Added in version 1.6.0)",
}
Added in version 0.5.0: public_certificate (optional) is public key certificate which will be sent through 'x5c' JWT header only for subject name and issuer authentication to support cert auto rolls.
Per specs, "the certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one." However, your certificate's issuer may use a different order. So, if your attempt ends up with an error AADSTS700027 - "The provided signature value did not match the expected signature value", you may try use only the leaf cert (in PEM/str format) instead.
Added in version 1.13.0: It can also be a completely pre-signed assertion that you've assembled yourself. Simply pass a container containing only the key "client_assertion", like this:
{
"client_assertion": "...a JWT with claims aud, exp, iss, jti, nbf, and sub..."
}
Added in version 0.5.0: It is a dictionary of extra claims that would be signed by by this ConfidentialClientApplication 's private key. For example, you can use {"client_ip": "x.x.x.x"}. You may also override any of the following default claims:
{
"aud": the_token_endpoint,
"iss": self.client_id,
"sub": same_as_issuer,
"exp": now + 10_min,
"iat": now,
"jti": a_random_uuid
}
A URL that identifies a token authority. It should be of the format https://login.microsoftonline.com/your_tenant By default, we will use https://login.microsoftonline.com/common
Changed in version 1.17: you can also use predefined constant and a builder like this:
from msal.authority import (
AuthorityBuilder,
AZURE_US_GOVERNMENT, AZURE_CHINA, AZURE_PUBLIC) my_authority = AuthorityBuilder(AZURE_PUBLIC, "contoso.onmicrosoft.com") # Now you get an equivalent of # "https://login.microsoftonline.com/contoso.onmicrosoft.com" # You can feed such an authority to msal's ClientApplication from msal import PublicClientApplication app = PublicClientApplication("my_client_id", authority=my_authority, ...)
(optional) It will be passed to the verify parameter in the underlying requests library This does not apply if you have chosen to pass your own Http client
(optional) It will be passed to the proxies parameter in the underlying requests library This does not apply if you have chosen to pass your own Http client
(optional) It will be passed to the timeout parameter in the underlying requests library This does not apply if you have chosen to pass your own Http client
(optional) Allows configuration of one or more client capabilities, e.g. ["CP1"].
Client capability is meant to inform the Microsoft identity platform (STS) what this client is capable for, so STS can decide to turn on certain features. For example, if client is capable to handle claims challenge, STS can then issue CAE access tokens to resources knowing when the resource emits claims challenge the client will be capable to handle.
Implementation details: Client capability is implemented using "claims" parameter on the wire, for now. MSAL will combine them into claims parameter which you will later provide via one of the acquire-token request.
AAD provides regional endpoints for apps to opt in to keep their traffic remain inside that region.
As of 2021 May, regional service is only available for acquire_token_for_client() sent by any of the following scenarios:
This parameter defaults to None, which means region behavior remains off.
App developer can opt in to a regional endpoint, by provide its region name, such as "westus", "eastus2". You can find a full list of regions by running az account list-locations -o table, or referencing to this doc.
An app running inside Azure Functions and Azure VM can use a special keyword ClientApplication.ATTEMPT_REGION_DISCOVERY to auto-detect region.
NOTE:
You should consider opting in/out region behavior on-demand, by loading azure_region=None or azure_region="westus" or azure_region=True (which means opt-in and auto-detect) from your per-deployment configuration, and then do app = ConfidentialClientApplication(..., azure_region=azure_region).
Alternatively, you can configure a short timeout, or provide a custom http_client which has a short timeout. That way, the latency would be under your control, but still less performant than opting out of region feature.
New in version 1.12.0.
MSAL has long been caching tokens in the token_cache. Recently, MSAL also introduced a concept of http_cache, by automatically caching some finite amount of non-token http responses, so that long-lived PublicClientApplication and ConfidentialClientApplication would be more performant and responsive in some situations.
This http_cache parameter accepts any dict-like object. If not provided, MSAL will use an in-memory dict.
If your app is a command-line app (CLI), you would want to persist your http_cache across different CLI runs. The following recipe shows a way to do so:
# Just add the following lines at the beginning of your CLI script import sys, atexit, pickle http_cache_filename = sys.argv[0] + ".http_cache" try:
with open(http_cache_filename, "rb") as f:
persisted_http_cache = pickle.load(f) # Take a snapshot except (
FileNotFoundError, # Or IOError in Python 2
pickle.UnpicklingError, # A corrupted http cache file
):
persisted_http_cache = {} # Recover by starting afresh atexit.register(lambda: pickle.dump(
# When exit, flush it back to the file.
# It may occasionally overwrite another process's concurrent write,
# but that is fine. Subsequent runs will reach eventual consistency.
persisted_http_cache, open(http_cache_file, "wb"))) # And then you can implement your app as you normally would app = msal.PublicClientApplication(
"your_client_id",
...,
http_cache=persisted_http_cache, # Utilize persisted_http_cache
...,
#token_cache=..., # You may combine the old token_cache trick
# Please refer to token_cache recipe at
# https://msal-python.readthedocs.io/en/latest/#msal.SerializableTokenCache
) app.acquire_token_interactive(["your", "scope"], ...)
Content inside http_cache are cheap to obtain. There is no need to share them among different apps.
Content inside http_cache will contain no tokens nor Personally Identifiable Information (PII). Encryption is unnecessary.
New in version 1.16.0.
Historically, MSAL would connect to a central endpoint located at https://login.microsoftonline.com to acquire some metadata, especially when using an unfamiliar authority. This behavior is known as Instance Discovery.
This parameter defaults to None, which enables the Instance Discovery.
If you know some authorities which you allow MSAL to operate with as-is, without involving any Instance Discovery, the recommended pattern is:
known_authorities = frozenset([ # Treat your known authorities as const
"https://contoso.com/adfs", "https://login.azs/foo"]) ... authority = "https://contoso.com/adfs" # Assuming your app will use this app1 = PublicClientApplication(
"client_id",
authority=authority,
# Conditionally disable Instance Discovery for known authorities
instance_discovery=authority not in known_authorities,
)
If you do not know some authorities beforehand, yet still want MSAL to accept any authority that you will provide, you can use a False to unconditionally disable Instance Discovery.
New in version 1.19.0.
A broker is a component installed on your device. Broker implicitly gives your device an identity. By using a broker, your device becomes a factor that can satisfy MFA (Multi-factor authentication). This factor would become mandatory if a tenant's admin enables a corresponding Conditional Access (CA) policy. The broker's presence allows Microsoft identity platform to have higher confidence that the tokens are being issued to your device, and that is more secure.
An additional benefit of broker is, it runs as a long-lived process with your device's OS, and maintains its own cache, so that your broker-enabled apps (even a CLI) could automatically SSO from a previously established signed-in session.
This parameter defaults to None, which means MSAL will not utilize a broker. If this parameter is set to True, MSAL will use the broker whenever possible, and automatically fall back to non-broker behavior. That also means your app does not need to enable broker conditionally, you can always set allow_broker to True, as long as your app meets the following prerequisite:
New in version 1.20.0.
It automatically provides nonce protection.
Scopes requested to access a protected API (a resource).
Most of the time, you can leave it empty.
If you requested user consent for multiple resources, here you will need to provide a subset of what you required in initiate_auth_code_flow().
OAuth2 was designed mostly for singleton services, where tokens are always meant for the same resource and the only changes are in the scopes. In AAD, tokens can be issued for multiple 3rd party resources. You can ask authorization code for multiple resources, but when you redeem it, the token is for only one intended recipient, called audience. So the developer need to specify a scope so that we can restrict the token to be issued for the corresponding audience.
def authorize(): # A controller in a web app
try:
result = msal_app.acquire_token_by_auth_code_flow(
session.get("flow", {}), request.args)
if "error" in result:
return render_template("error.html", result)
use(result) # Token(s) are available in result and cache
except ValueError: # Usually caused by CSRF
pass # Simply ignore them
return redirect(url_for("index"))
(Required) Scopes requested to access a protected API (a resource).
If you requested user consent for multiple resources, here you will typically want to provide a subset of what you required in AuthCode.
OAuth2 was designed mostly for singleton services, where tokens are always meant for the same resource and the only changes are in the scopes. In AAD, tokens can be issued for multiple 3rd party resources. You can ask authorization code for multiple resources, but when you redeem it, the token is for only one intended recipient, called audience. So the developer need to specify a scope so that we can restrict the token to be issued for the corresponding audience.
You use this method only when you have old RTs from elsewhere, and now you want to migrate them into MSAL. Calling this method results in new tokens automatically storing into MSAL.
You do NOT need to use this method if you are already using MSAL. MSAL maintains RT automatically inside its token cache, and an access token can be retrieved when you call acquire_token_silent().
The scopes associate with this old RT. Each scope needs to be in the Microsoft identity platform (v2) format. See Scopes not resources.
See this page for constraints of Username Password Flow. https://github.com/AzureAD/microsoft-authentication-library-for-python/wiki/Username-Password-Authentication
The current app is a middle-tier service which was called with a token representing an end user. The current app can use such token (a.k.a. a user assertion) to request another token to access downstream web API, on behalf of that user. See detail docs here .
The current middle-tier app has no user interaction to obtain consent. See how to gain consent upfront for your middle-tier app from this article. https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow#gaining-consent-for-the-middle-tier-application
It is done either by finding a valid access token from cache, or by finding a valid refresh token from cache and then automatically use it to redeem a new access token.
This method will combine the cache empty and refresh error into one return value, None. If your app does not care about the exact token refresh error during token cache look-up, then this method is easier and recommended.
Internally, this method calls acquire_token_silent_with_error().
It is done either by finding a valid access token from cache, or by finding a valid refresh token from cache and then automatically use it to redeem a new access token.
This method will differentiate cache empty from token refresh error. If your app cares the exact token refresh error during token cache look-up, then this method is suitable. Otherwise, the other method acquire_token_silent() is recommended.
An account can later be used in acquire_token_silent() to find its tokens.
Default value is "code" for an OAuth2 Authorization Code grant.
You could use other content such as "id_token" or "token", which would trigger an Implicit Grant, but that is not recommended.
A cryptographically random value used to mitigate replay attacks. See also OIDC specs.
Can be one of "consumers" or "organizations" or your tenant domain "contoso.com". If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience. More information on possible values here and here.
Later when the response reaches your redirect_uri, you can use acquire_token_by_auth_code_flow() to complete the authentication/authorization.
Can be one of "consumers" or "organizations" or your tenant domain "contoso.com". If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience. More information on possible values here and here.
OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated. If the elapsed time is greater than this value, Microsoft identity platform will actively re-authenticate the End-User.
MSAL Python will also automatically validate the auth_time in ID token.
New in version 1.15.
{
"auth_uri": "https://...", // Guide user to visit this
"state": "...", // You may choose to verify it by yourself,
// or just let acquire_token_by_auth_code_flow()
// do that for you.
"...": "...", // Everything else are reserved and internal
}
The caller is expected to:
One of the parameters accepted by both PublicClientApplication and ConfidentialClientApplication is the TokenCache.
Although it maintains tokens using unified schema across all MSAL libraries, this class does not serialize/persist them. See subclass SerializableTokenCache for details on serialization.
Known side effects: This function modifies the input event in place.
You can subclass it to add new behavior, such as, token serialization. See SerializableTokenCache for example.
This class does NOT actually persist the cache on disk/db/etc.. Depending on your need, the following simple recipe for file-based persistence may be sufficient:
import os, atexit, msal
cache = msal.SerializableTokenCache()
if os.path.exists("my_cache.bin"):
cache.deserialize(open("my_cache.bin", "r").read())
atexit.register(lambda:
open("my_cache.bin", "w").write(cache.serialize())
# Hint: The following optional line persists only when state changed
if cache.has_state_changed else None
)
app = msal.ClientApplication(..., token_cache=cache)
...
Known side effects: This function modifies the input event in place.
Microsoft
2023, Microsoft
| February 11, 2023 | 1.21.0 |