Privacy Policy

AppTesting — part of the AppConfig² suite

Last updated: June 7, 2026

1. Overview

AppTesting is a read-only analysis and troubleshooting tool for Microsoft Entra ID application registrations. It provides the full testing and inspection capabilities of AppConfig — auth flow testing, token analysis, permission inspection, conditional access review — without the ability to create, modify, or delete any objects in your Entra ID tenant. AppTesting is designed for scenarios where you need deep diagnostic visibility but want a guarantee that no configuration changes can result from the session.

Key Privacy Principle: AppTesting never writes to, modifies, or deletes any data in your Entra ID tenant. All Graph API access is read-only. The application operates entirely within your browser, querying your Entra ID environment directly via Microsoft Graph API. No tenant data is transmitted to or stored on AppTesting servers.

Exception — Client Credentials Testing: AppTesting includes an optional Auth Flow Tester that uses a secure Azure Function backend (/get-token) to test the OAuth 2.0 client credentials flow. This backend processes credentials in-memory only and never stores them. See Section 4.4 for full details. This is the only data path that involves AppTesting infrastructure.

2. Information AppTesting Accesses

AppTesting accesses your Entra ID tenant data on behalf of the authenticated user. All Graph API access is read-only — AppTesting holds no write permissions and cannot modify your tenant.

2.1 Authentication Information

  • User identity and basic profile (name, email, tenant ID) — to verify access and display the signed-in user
  • Authentication tokens for Microsoft Graph API access — handled by MSAL.js using Authorization Code Flow + PKCE, stored in sessionStorage (per-tab isolation), never transmitted to AppTesting servers

Access Method: Direct browser-to-Microsoft authentication. AppTesting never sees or handles your password or MFA response.

2.2 Application Registration Data (Read only)

  • Application display names, application IDs, object IDs, and manifest properties
  • API permissions (delegated and application roles) granted to each registration
  • Authentication settings, redirect URIs, and sign-in audience configurations
  • Credential metadata — key IDs, expiry dates, display names (actual secret values are never returned by the Graph API and are never accessible)
  • Claims mapping policies assigned to applications
  • Optional claims configurations from application manifests
  • Federated identity credential configurations

Access Method: Direct browser-to-Microsoft Graph API read queries using delegated read permissions. Data is processed in-memory within your browser tab. No data is retained after your session ends.

2.3 Directory Information (Read only)

  • User profile information for resolving owner identities in the UI
  • Conditional access policies and their assignments — for review and analysis only
  • Directory schema and extension attributes
  • Service principal objects for cross-referencing application data

Access Method: Direct browser-to-Microsoft Graph API read calls. No data is retained after your session ends.

3. Local Data Storage & Session Isolation

AppTesting uses browser-side storage mechanisms to support its functionality. No browser-stored data is transmitted to AppTesting servers.

3.1 sessionStorage (Authentication & Session Cache)

  • MSAL.js authentication tokens and account information
  • Graph API response cache for read operations — reduces redundant API calls within a session
  • Active application context and UI state (selected filters, active view)
  • Scope: Isolated per browser tab. All data is automatically discarded when the tab or browser is closed.
  • No cross-tab sharing: Each tab maintains a fully independent session.

3.2 localStorage (Preferences & Cache)

  • User interface preferences (e.g., theme selection)
  • Application metadata cache for performance (purged automatically every 5 minutes)
  • No tenant configuration data is persisted to localStorage — AppTesting does not store backup snapshots (it makes no changes that would need to be reversed)

3.3 Cache Management

  • Metadata cache is automatically purged every 5 minutes
  • All session data is cleared on logout or tab close
  • You can clear all browser-stored data at any time via browser settings
  • No cached data is transmitted to AppTesting servers

4. How AppTesting Uses Accessed Data

Data accessed via Microsoft Graph is used solely to provide AppTesting's read-only analysis and testing capabilities. No data is used for advertising, profiling, or any purpose beyond the specific function you invoke.

4.1 Authentication Flow Analysis

  • Simulate and analyse authentication flows — OAuth 2.0 and OpenID Connect — by executing token requests on behalf of the signed-in user and inspecting the results
  • Validate authentication configurations without modifying any settings

4.2 Token Decoding & Analysis

  • Decode and inspect JWT and access tokens — identifying claims, signatures, expiration, and audience values
  • Token decoding occurs entirely client-side — token values are never transmitted to AppTesting servers

4.3 Application & Permission Inspection

  • Read and display application registration details, API permissions, credential metadata, and manifest properties
  • Analyse permission grants and identify potential security risks — read-only analysis, no changes made
  • Review conditional access policy assignments and their impact on application access

4.4 Client Credentials Testing (Optional Feature)

AppTesting includes an optional Auth Flow Tester for validating the OAuth 2.0 client credentials flow. This is the only feature that involves AppTesting backend infrastructure:

  • Purpose: Allows you to verify that a set of client credentials (application ID and secret or certificate) can successfully obtain an access token from Microsoft
  • Data Processed: Client ID, client secret or certificate, tenant ID — transmitted to AppTesting's Azure Function (/get-token)
  • Processing: The function makes a token request to Microsoft's token endpoint on your behalf and returns the result to your browser
  • Retention: Credentials are processed in-memory only. They are never logged, stored, or persisted in any form
  • Logging: Only non-sensitive metadata is logged (client ID, timestamp, success/failure status — no secrets or tokens)
  • Graph API Impact: Zero. This flow tests whether credentials are valid by calling Microsoft's token endpoint only — it does not read or write any data in your Entra ID tenant
  • Usage: Completely optional. All other AppTesting functionality works without using this endpoint

Why a Backend Service is Required: The OAuth 2.0 client credentials flow (defined in RFC 6749 Section 4.4) requires transmitting sensitive credentials to obtain an access token. Browser-based applications must not handle these credentials directly. Any tool that tests client credentials — including AppTesting — must use a backend service. This is a requirement of the OAuth 2.0 specification, not a choice specific to AppTesting.

AppTesting Implementation: The /get-token Azure Function receives credentials over encrypted HTTPS, makes the token request in-memory, and returns the result. Credentials are never logged or stored.

Summary: Except for the optional client credentials testing feature, no tenant data is transmitted to or stored on AppTesting servers. The client credentials testing feature does not process any personally identifiable information, as the client credentials flow does not involve user data.

5. What AppTesting Does Not Do

The following operations are architecturally impossible in AppTesting because the application holds no write permissions against Microsoft Graph API:

  • Create, modify, or delete any application registrations or service principals
  • Create, rotate, or revoke credentials (secrets or certificates)
  • Grant or revoke API permissions or consent
  • Modify any application manifest properties
  • Create or modify claims mapping policies
  • Provision or deprovision users or group memberships
  • Modify any tenant configuration or conditional access policy
  • Store any tenant configuration data persistently (beyond the current browser session)
  • Share your data with third parties for any purpose

6. Permissions Model

AppTesting requests the minimum delegated read-only permissions necessary to provide its analysis capabilities. All permissions are delegated (on behalf of the signed-in user) — AppTesting cannot perform any operation that the signed-in user's own Entra ID role does not permit, and it is further constrained to read-only operations regardless of the user's role.

  • User.Read — read the signed-in user's profile
  • Application.Read.All — read all application registrations and service principals in the tenant
  • Policy.Read.All — read conditional access policies and claims mapping policies for analysis
  • openid, profile, offline_access — standard OIDC scopes for authentication and silent token renewal

No write permissions (ReadWrite variants) are ever requested. No application (app-only) permissions are used.

7. Data Transmission & Security

7.1 Architecture

  • AppTesting is hosted as an Azure Static Web App — static HTML, CSS, and JavaScript with no backend compute for read operations
  • All read operations occur directly between your browser and Microsoft Graph API
  • The only AppTesting backend infrastructure is the optional /get-token Azure Function for client credentials testing (see Section 4.4)

7.2 Encryption

  • All communication with Microsoft Graph uses HTTPS/TLS
  • MSAL.js tokens are stored in sessionStorage with browser-native security protections
  • Client credentials sent to the /get-token endpoint are encrypted in transit and never persisted

7.3 Authentication Security

  • Authorization Code Flow with PKCE — no implicit flow, no client secrets embedded in the app
  • Tokens stored in sessionStorage provide per-tab isolation — closing the tab discards all tokens
  • Single-tenant enforcement — AppTesting validates that the authenticated tenant matches the configured tenant

7.4 Logging & Monitoring

  • Client-side: No logging of sensitive data
  • Static hosting: Azure Static Web Apps platform may collect standard hosting telemetry (request counts, response codes) that contains no tenant data — governed by Microsoft's privacy practices
  • Azure Function (/get-token): Minimal operational logs only — client ID, timestamp, success/failure status. No secrets, tokens, or user data. Retained per Azure platform defaults (typically 30–90 days).
  • Never Logged: Client secrets, access tokens, refresh tokens, or any personal data

8. Third-Party Services

AppTesting integrates exclusively with Microsoft services:

  • Microsoft Entra ID: Authentication and identity management (direct browser-to-Microsoft connection)
  • Microsoft Graph API: Read-only access to tenant application data (direct browser-to-Microsoft connection)
  • Azure Static Web Apps: Application hosting (static asset delivery only)
  • Azure Functions: Optional /get-token endpoint for client credentials flow testing only

No third-party analytics, advertising, tracking, or data-sharing services are used. No tenant data is shared with any external party other than Microsoft for the purpose of authenticating you and querying your own tenant.

9. Data Retention & Deletion

9.1 No Persistent Tenant Storage

  • AppTesting holds no server-side databases, file stores, or persistent caches containing tenant data
  • All tenant data is discarded when you close your browser tab
  • There is no "delete my data" process required because no tenant data is ever retained server-side

9.2 Operational Logs

  • The /get-token Azure Function records non-sensitive operational metadata (client ID, timestamp, result status) per Azure platform defaults (typically 30–90 days)
  • No secrets, tokens, or personal data are ever logged
  • Logs are automatically purged per the configured Azure retention policy

9.3 User Control

  • Revoke AppTesting's access at any time via Microsoft Entra Admin Center → Enterprise Applications → AppTesting → Permissions → Revoke consent
  • Closing the browser tab immediately terminates the session and clears all cached data
  • Theme preferences stored in localStorage can be cleared via browser settings

10. Compliance

10.1 GDPR

AppTesting's architecture is aligned with GDPR's data minimisation and storage limitation principles: only the data necessary to support the diagnostic function you invoke is accessed, and it is held only for the duration of the active browser session. Because no tenant data is transferred to or stored by AppTesting (beyond the limited operational logs noted above), there is minimal cross-border transfer or data controller relationship to establish beyond what already exists between your organisation and Microsoft.

10.2 Microsoft Trust Centre

AppTesting builds on Microsoft's security and compliance infrastructure. The underlying data governance of your Entra ID environment — including its certifications (ISO 27001, SOC 2, etc.) — applies to the data AppTesting reads via Graph API.

11. Changes to This Policy

We may update this Privacy Policy to reflect changes in AppTesting's functionality or applicable regulations. Significant changes will be communicated through in-application notifications and updates posted on the AppTesting landing page. Continued use after such updates constitutes acceptance of the revised policy.

12. Contact

For privacy-related questions or concerns about AppTesting:

EU data subjects have the right to lodge a complaint with their local supervisory authority.