DOYDL Technologies · azauthlib Desktop Application

Privacy Policy

How the desktop app handles connection profiles, credentials, authentication, local records, and optional online interactions.

1. Scope and privacy roles

This Policy describes the standard azauthlib desktop application developed by DOYDL and the interactions it initiates. "Personal information" includes information that identifies or can reasonably be linked to a person, household, or device under applicable law. An identifier that is not a password may still be sensitive organizational information or become personal information when combined with other records.

Local processing is not the same as receipt by DOYDL. The App can handle profiles and secrets on your device without uploading those values to DOYDL. DOYDL does not acquire remote access to your files merely by publishing the App. Information you choose to send to support may be received by DOYDL and the communication providers involved.

Where DOYDL determines why and how information it actually receives is processed, it may act as a controller or equivalent responsible business. Where your employer or another organization determines how the App is deployed and how tenant information is used, that organization has its own obligations and may be the appropriate contact for your request. A software license alone does not establish a hosted processing service or a data-processing agreement.

Microsoft administers its identity services and account/tenant processing under the relevant Microsoft and organizational arrangements. GitHub, your browser, your operating system, and other destinations have separate practices. A modified build or another program embedding the azauthlib Python library may behave differently and needs its own accurate notice.

2. Information the App handles

Technical inventory of the desktop implementation described in this Policy
CategoryExamples and purposeUsual handling
Profile and configuration dataConnection name, local profile ID, selected profile, tenant/directory ID, client/application ID, authentication method, and an authority value where configured.Stored locally to display and reuse connections. Loading the bundled policies does not transmit these values.
Client secretsA secret value you enter for client-credentials authentication.Handled in process memory, saved through the configured OS keyring backend, and sent to the Microsoft identity token endpoint when that authentication method is tested.
Authentication informationRequested scopes, token responses and claims, account-related identifiers, short-lived device codes, verification URLs, and authentication errors.Exchanged as needed with identity services. Desktop-test token caching is in memory, distinct from the separate library's persistent-cache options.
Saved test outcomesPassed/failed status, local profile ID, a keyed credential fingerprint, and an integrity signature.Stored locally to recognize whether a result still matches saved credentials; raw tokens and raw secret values are not written into the outcome record.
Preferences and runtime informationDisplay settings, file/lock metadata, UI or dependency warnings, HTTP status categories, error identifiers, and potentially correlation IDs in library diagnostics.Local preferences and process/console diagnostics. What a launcher, host application, or endpoint system retains depends on its configuration.
Support information you provideName or account handle, email if used, message content, app/OS version, and redacted attachments you choose to submit.Received through the channel you use. Public issues are public; private reporting and correspondence have different recipients.

Do not put secrets, sensitive personal details, or a customer's name in a profile name unless necessary. The App does not need your Microsoft account password in its own configuration form, your payment-card information, contacts permission, camera access, or microphone access to manage a connection.

3. Where information comes from

The App receives configuration from values you enter, existing profile/configuration files, and the OS credential store. Authentication services return metadata, codes, tokens, and status information when you initiate a test. The local environment supplies display, filesystem, and network information needed to run the App.

The Python library can also accept credentials through an explicitly chosen environment file, environment variables, or direct caller input. Those developer-controlled paths are not a claim that the desktop App searches your entire disk or silently imports arbitrary files.

DOYDL receives support content from the sender through the communication channel used. A public repository handle may accompany an issue. This does not mean DOYDL routinely obtains your Microsoft account profile, browser history, local documents, or tenant directory contents.

4. Network requests and who receives them

4.1 Local legal documents

The desktop Terms of Use and Privacy Policy are included in the application package. The App reads those HTML files locally and prepares their text for native drawers during interface loading. It does not fetch website policies at startup, run website scripts, load tracking pixels, or send a legal-notice request to doydl.studio.

4.2 Tests you choose to start

When you choose Test connection, the App uses MSAL to communicate with the Microsoft identity platform. The desktop transport restricts its own identity HTTP requests to the Microsoft public-cloud host login.microsoftonline.com over verified HTTPS. It sends the configuration and authentication material required by the chosen flow. Your browser's sign-in journey may visit additional Microsoft, organizational, or federated identity destinations.

For client credentials, the token request includes the client secret. For interactive and device-code flows, account selection, password entry, multifactor checks, and consent are handled through the identity-provider experience. The current test requests Microsoft Graph's .default scope; permissions depend on your registration and consent.

Identity services and relevant network infrastructure receive ordinary connection information, including IP addresses, request times, and protocol metadata. A DNS resolver can see domain lookups; a managed organizational proxy may observe additional information under its own arrangements.

The test checks token issuance. It does not subsequently retrieve Graph mail, files, contacts, calendars, or directory contents. Other programs using the library and your credentials may do so under their own control and must provide their own disclosures.

4.3 Links, correspondence, and distribution

Following a website, repository, email, or sign-in link invokes the relevant external handler. The browser or email application can apply its account sessions, history, cookies, extensions, and privacy settings. Website browsing is separate from local policy loading and is subject to the destination's notices.

Downloads from GitHub, PyPI, package managers, or another distributor are governed by that distributor's practices. Privacy and support correspondence passes through the email or repository platform you use. The App does not automatically submit your local profiles, credentials, or console output to those channels.

5. Local storage and credential protection

Application data locations are selected using platform-specific user configuration and cache directories. On Windows, configuration normally resides under %LOCALAPPDATA%\azauthlib; cache and other operating-system paths can vary by platform or environment. A custom library token path may point elsewhere.

  • profiles.json records profile IDs, names, and the active selection.
  • The default .env and per-profile configuration files contain non-secret application values, such as tenant and client IDs and the authentication method.
  • ui_preferences.json stores display preferences, where the corresponding feature is used.
  • connection-test-results.json stores outcome records, fingerprints, and signatures rather than raw token responses or raw secrets.
  • The configured keyring backend stores client secrets under the azauthlib service, keyed by client ID. A separate azauthlib.connection-tests entry can hold the fingerprint key.
  • Known profile files removed through the App may be moved into a removed-profiles archive within configuration or cache storage.

Profile and preference files are not themselves represented as encrypted vaults. A tenant ID or client ID is generally an identifier, not a password, but can still disclose organizational relationships. Protect those files and their backups accordingly.

The strength and accessibility of secret storage depend on the actual keyring backend and OS account. The intended Windows backend uses the OS credential facilities; another platform or a custom backend may differ. The App reports a credential-store failure rather than deliberately writing the client secret into its public configuration file.

Other software with the appropriate account or administrative access may be able to obtain protected data. Disk encryption, endpoint controls, and a locked session remain important; this Policy does not guarantee protection against a compromised operating system.

6. Authentication information and tokens

The desktop Test connection implementation uses a fresh in-memory MSAL token cache for each test, disables MSAL's personally identifiable information logging option, and reports a summarized status rather than exposing a raw token in the interface. Public-client test flows explicitly exclude the offline_access scope.

Temporary tokens, claims, codes, configuration snapshots, and secrets may exist in process memory while work is performed. "Memory-only cache" does not guarantee cryptographic wiping, zero retention by the OS, or exclusion from swap, crash dumps, security software, or debugging tools. The App does not promise that every sensitive memory allocation is overwritten immediately.

The separate library behaves differently: callers of the azauthlib authentication library can use persistent MSAL caches that may contain account records and access, refresh, or identity-token material. Persistence uses OS-backed encryption by default and fails if secure persistence is unavailable unless a caller explicitly enables plaintext caching. A custom library integration needs to disclose the settings it actually uses.

Token expiry, consent, sign-in events, and revocation are controlled by Microsoft and the relevant organization. Closing the App or removing its local records does not guarantee immediate invalidation of an already issued token or deletion of Microsoft-side records.

7. Clipboard, browser, and device exposure

If you choose Copy for an active device-code sign-in, the App places that code on the system clipboard. The App does not automatically clear the clipboard afterward. Clipboard history, device synchronization, remote-desktop tools, and other applications may preserve or read the copied content according to their permissions.

Some notice text can be selected and copied. Any manual copying of a credential or configuration value outside the App creates another potential copy. Keep screenshots, screen recordings, shared displays, and support attachments free of sensitive values.

A browser sign-in may leave browser cookies and account sessions even though the App's token cache was temporary. Browser privacy settings and the identity provider's sign-out/revocation tools control those records, not the App's Remove connection button.

8. Analytics, advertising, tracking, and automated decisions

The standard desktop implementation contains no integrated advertising SDK, behavioral analytics collector, automatic cloud upload of profiles, or automatic crash-report submission service. It does not create an App-level advertising identifier or use connection configuration to build an advertising profile.

The App does not sell local profile information or transmit it for cross-context behavioral advertising. It does not make automated eligibility, credit, employment, insurance, or similarly significant decisions about you. A connection-test result is a technical authentication outcome, not an assessment of your character or entitlement to benefits.

These statements concern the desktop App, not every independent service you access. Microsoft and your organization may apply identity, fraud, diagnostic, or conditional-access controls. A website opened in a browser, an operating system, a package distributor, or an organizational monitoring tool may process information under its own notices and settings.

Bundled policy documents contain no scripts, remote fonts, embedded images, forms, or tracking resources. Loading them does not set website cookies or contact an analytics endpoint. This notice does not authorize a future tracking feature without the disclosures and permissions required for that feature.

9. Purposes and, where applicable, legal bases

The App handles local information to carry out your configuration, profile-selection, authentication-testing, and display instructions. Installing the App or reading a notice is not blanket consent to unrelated processing. Your organization remains responsible for the legal basis and authority for its deployment and tenant activity.

Purposes of the processing described in this Policy
PurposeInformation involvedBasis and responsibility
Run local featuresProfiles, preferences, local outcome records, and necessary credential handling.Processing carries out your instructions on your device. Distribution of the App does not give DOYDL access to local-only information or establish a hosted processor relationship.
Authenticate at your requestIdentifiers, requested scopes, credentials appropriate to the flow, and identity responses.Microsoft and the responsible tenant organization administer identity processing under their applicable arrangements. Granting an API permission is not a substitute for the organization's privacy obligations.
Respond to support and privacy requestsContact details, correspondence, and relevant redacted diagnostics you submit.Where privacy laws require a basis, we process correspondence for our legitimate interests in answering requests, resolving defects, and securing the App, subject to applicable balancing requirements; to perform a relevant agreement where necessary; or to meet applicable legal obligations. We rely on consent where that is the required basis.
Meet legal obligations and address claimsRelevant information actually held by DOYDL.Processing is limited to applicable legal obligations or legitimate interests in establishing, exercising, or defending claims, subject to the requirements of the law that applies.

Where consent is used, you can withdraw it by contacting privacy@doydl.studio. Withdrawal does not make earlier lawful processing unlawful; it may prevent an optional activity dependent on that consent. It does not revoke a Microsoft credential or delete another controller's records.

A new purpose requires an appropriate basis and any additional notice or permission required by law. This general-purpose App does not establish authorization to process special-category, criminal-offense, or other specially protected information in a deployment.

10. Disclosures and third-party roles

The standard App does not route connection-test credentials through a DOYDL authentication relay. Necessary authentication material goes to the identity service for the flow you initiate. That service and your tenant administrator may retain sign-in records or account/security information under their own arrangements.

Correspondence you send to DOYDL is handled through the email or repository channel you choose and the communication/storage services necessary to receive and answer it. Public GitHub submissions are processed on GitHub's platform; email is transmitted through the participating email providers. Access is limited to handling the communication and related legitimate purposes described in this Policy. Contact privacy@doydl.studio for information about recipients relevant to your request.

GitHub receives information submitted through its platform. Public issues and discussions can be seen by anyone and copied by search engines or other parties. For vulnerabilities, use the private process in SECURITY.md. Do not submit a credential to establish ownership of a connection.

Where legally required or permitted, information actually held may need to be disclosed to an authority, professional adviser, or another party in order to comply with a valid legal process, respond to a security incident, establish or defend a claim, or protect rights. Disclosures should be limited to the information and purpose justified by the circumstances; this is not authorization for unrestricted sharing.

If a business reorganization would involve transferring personal information held by DOYDL, the transfer must have a valid legal basis and appropriate notice and safeguards. A corporate transaction does not, by itself, transfer a private keyring or local profile that DOYDL never possessed.

External references: Microsoft Privacy Statement and GitHub General Privacy Statement. These providers' notices, and any organizational agreement governing your use, describe their own processing; DOYDL cannot amend them.

11. Retention, archives, and copies

Retention is not the same for every category. The App has no single "delete everything" timer, and DOYDL cannot remotely erase records it does not control.

Retention and deletion behavior
CategoryRetention or deletion behavior
Active profiles and preferencesRemain in local files until changed, removed through the relevant workflow, or manually cleaned up. No automatic age-based expiry is implemented for these files.
Removed-profile archivesKnown files are recoverably moved into removed-profiles. The App does not automatically purge these archives after a fixed period.
OS-stored secrets and fingerprint keyCan remain after profile removal or uninstall. They require separate review and cleanup; deleting a shared entry can affect another profile or program.
Test outcomesSaved locally while useful to the App; removing a profile through the standard desktop workflow attempts to remove its outcome record. A fingerprint no longer matching current credentials makes the old outcome untrusted, but is not a promise that every old byte or backup was erased.
Desktop-test tokens and bundled policy textDesktop test tokens use a temporary memory cache. Policy HTML is shipped as package data and kept with the installed release; prepared drawer text is held in session memory. OS and memory artifacts are subject to the limitations in Section 6.
Library token cachesMay persist until cleared by the integration or user. Encryption is the default, not an expiry or deletion policy. Profile removal can archive a known cache; custom paths and backups need separate handling.
Support and privacy correspondenceWe retain correspondence while a request is active and afterward only as needed to complete agreed follow-up, document the resolution and legally required handling, address a related security issue, or establish or defend a claim within the applicable recordkeeping or limitation period. A legal hold can extend retention for the affected records. When those purposes no longer apply, we delete or de-identify the information under our control, subject to applicable backup and platform limits.
Browser, Microsoft, organizational, and backup recordsControlled by the relevant provider, organization, or backup operator, not by the App's profile-removal workflow. Their separate retention rules apply.

If a legal hold or statutory requirement prevents deletion of information DOYDL actually holds, retention should be limited to the applicable purpose and period. Residual backup copies require their own lifecycle and restrictions; a promise of instant universal deletion should not be inferred.

12. Removing information, uninstalling, and revoking access

Removing a connection is deliberately recoverable. It removes the active profile entry, archives known profile files, and keeps shared OS secrets. You can have zero active profiles, but that does not establish that no related files or credentials remain.

  1. Cancel a pending test and close applications using the affected profile before cleanup.
  2. Remove the intended connection in the App. Verify that you selected the right profile.
  3. Review the corresponding removed-profiles archives and any other authorized copies before deciding what to delete. The App does not certify secure erasure.
  4. Use the OS credential-management tools to review the specific client-ID secret and any App fingerprint-key entry. Confirm they are not needed by another profile or program.
  5. Review separate library caches, custom paths, backups, clipboard history, and browser sessions if complete local cleanup is your goal.
  6. If access must end, use Microsoft/tenant controls to revoke or rotate secrets, review consent, and terminate sessions where appropriate. Local deletion is not revocation.

Uninstallers, package managers, and manual source removal may leave user configuration and keyring data in place. Deleting a program folder alone is not a reliable method of removing all related data. Consult your administrator if the device, credentials, archives, or retention rules are organization-managed.

Do not send DOYDL your actual secret, token cache, or complete profile directory to request deletion. DOYDL cannot erase a local file or a Microsoft-controlled record that it does not possess; it can explain the relevant workflow and address information it does hold.

13. Your choices and controls

  • Local profile management: edit or remove profiles and choose not to store unnecessary information. Use non-sensitive connection names.
  • Optional authentication: do not choose Test connection if you do not want that test's identity traffic. You can cancel an ongoing test; cancellation cannot retract information already sent or undo provider-side records.
  • Permissions and secrets: manage grants, registration settings, credential rotation, and account access through your organization and Microsoft.
  • Offline legal access: Terms and Privacy load from the installed package. No website connection is needed to read them; external links are optional.
  • Support: choose whether to submit information; redact it first. Do not use a public issue for a private privacy request.
  • Browser and clipboard: use their settings to manage cookies, sessions, clipboard history, and cross-device copies.

The App's local profile handling is not conditional on agreeing to marketing or submitting a support request. Declining a necessary authentication input can prevent that authentication flow from working. A missing local policy file does not require an automatic website request.

14. Privacy rights and how to request them

Depending on your location, the applicable law, and the processing involved, you may have rights to obtain information about processing; access or obtain a copy; correct inaccuracies; request deletion; restrict processing; receive portable information; object to certain processing; withdraw consent where it is used; or complain to a competent supervisory authority. Rights may have lawful exceptions and do not all apply to every record or organization.

Use the private contact in Section 19 for information DOYDL actually holds. Identify the nature of the request and the relevant interaction, such as the subject and approximate date of a support message. DOYDL should request only proportionate verification and must not require a Microsoft password, client secret, access token, or a new App account to consider a request.

Responses must follow applicable legal deadlines and permitted extensions. If a request cannot be fulfilled, the response should explain the applicable reason and any available review, appeal, complaint, or regulatory route. A public repository issue is not a required gateway to statutory rights.

Contact your employer/tenant administrator for its deployment records and Microsoft or another provider for records under its control. For local-only files, use the device controls described above. These distinctions identify the responsible party; they do not remove obligations DOYDL actually has.

United States state privacy laws

Where a relevant state law applies to DOYDL and the processing, eligible residents may have rights to know/access, correct, delete, receive a copy, or opt out of covered sale, targeted advertising/sharing, or certain profiling. Some laws provide an appeal or protection against unlawful discrimination for exercising rights. California law may also provide rights concerning sensitive personal information.

The desktop App has no advertising or sale/sharing mechanism to disable. These regional rights apply where the relevant law covers the responsible business and processing. They do not imply that every law applies to every user or every local file. Contact us privately for a request concerning information we actually hold.

European Economic Area, United Kingdom, and other regions

Where applicable, you may complain to the competent supervisory authority and exercise the rights provided by the relevant law. Contact privacy@doydl.studio for questions about DOYDL-handled correspondence, its recipients, or applicable safeguards. You do not have to give up access to a regulator or court in order to contact us.

15. International processing

Local profile storage does not mean that an identity provider or a communication service operates only in your country. Microsoft sign-in, GitHub, email, and organizational infrastructure may process information in other jurisdictions under their applicable arrangements.

For correspondence you send to DOYDL, the destination and the communication services involved determine where information is transmitted and handled. Where transfer restrictions apply to a transfer under our responsibility, we use a legally permitted mechanism and required safeguards. You can contact privacy@doydl.studio for information relevant to your interaction and any available safeguard documentation.

This Policy does not claim that DOYDL holds a particular framework certification or guarantees data residency. Merely using the App is not consent to every international transfer and does not replace the safeguards required by applicable law.

16. Security and incident reports

The App separates public configuration from keyring secrets, uses verified HTTPS for its desktop test transport, summarizes test errors, and uses keyed fingerprints rather than raw secrets in saved outcome records. OS-backed encryption is the default for persistent library token caches.

These measures have limits. Local account compromise, malware, administrative access, memory capture, a custom keyring backend, an explicitly plaintext library cache, a malicious dependency, or an improperly secured backup can expose information. The App is not represented as independently certified or immune to breach.

Console/QML warnings and host-application logging may include technical details such as paths or correlation identifiers. The App does not automatically upload its console output, but you or an organizational tool may capture it. Inspect and redact diagnostic material before sharing it.

Use the private reporting process in SECURITY.md for a vulnerability. For a suspected compromise of your tenant, account, or device, also notify the responsible administrator and rotate or revoke affected credentials. Where DOYDL has a legally reportable incident involving information under its responsibility, applicable assessment and notification requirements govern; notification deadlines are determined by applicable law, and no guarantee is made that an incident cannot occur.

17. Children and sensitive information

The App is intended for authorized developer and administrative use, not as a child-directed product. It does not implement an age-verification system or a parental-consent service. Applicable minimum-age, consent, and organizational rules still apply to a deployment.

If you believe a child has submitted personal information to DOYDL in circumstances requiring action, use the private contact in Section 19. DOYDL must assess and handle information actually received according to applicable law; the local software cannot identify the age of every device user from a profile.

Authentication information is sensitive even when it is not classified as a special category under a particular law. Do not put health, biometric, financial, precise-location, government-identifier, or other unnecessary sensitive information into profile names, support messages, or screenshots. Access to a regulated tenant is not a claim that the App satisfies that sector's compliance obligations.

18. Changes and scope of this Policy

This Policy is effective on the date shown above and describes the standard desktop release in which it is bundled. A modified build or another program embedding the library may process information differently and must provide its own accurate notice.

Revisions identify their effective date. Material changes in processing require appropriate notice and any additional legal basis or consent required before the new processing begins. A policy update cannot retroactively authorize an unrelated use of information.

The installed App loads this document locally rather than silently replacing it with website text. A later application update may bundle a newer policy. Future telemetry, hosted credential functions, automatic update checking, or additional provider integrations require disclosures reflecting their actual behavior.

19. Contact information

Responsible publisher: DOYDL Technologies

Privacy inquiries and rights requests: privacy@doydl.studio

Legal inquiries: legal@doydl.studio

Business mailing address: DOYDL Technologies, 11166 Fairfax Blvd, Suite 500 #1378, Fairfax, VA 22030, United States

Website: doydl.studio

Repository: doydl-technologies/azauthlib

Private security reports: follow SECURITY.md.

Send private privacy inquiries to privacy@doydl.studio. Do not send a password, client secret, full token, or unredacted profile to verify your identity. Public GitHub issues are not a substitute for this private channel.