How UserDesk protects your tenant

UserDesk does not store Microsoft 365 passwords, admin credentials, or long-lived API keys. Authentication is handled entirely by Microsoft's OAuth 2.0 authorization code flow with PKCE. When a user signs in, they authenticate directly with Microsoft — UserDesk never sees or handles their password.

After authentication, Microsoft issues a short-lived access token (valid for ~1 hour) and a refresh token. These tokens are encrypted inside a signed JWT session cookie stored in the user's browser — not in our database.

Our database contains only subscription and portal metadata:

• Tenant ID —Your Microsoft 365 tenant identifier (a GUID). This identifies your organization but grants no access on its own.
• User email & name —The email and display name of each person who has signed into the portal. Used for the audit log and role assignments.
• Portal roles —Whether each user is an Admin, Member, or Viewer within UserDesk.
• Subscription status —Your Stripe subscription ID and billing status (active, past due, canceled).
• Audit log entries —A record of actions taken through the portal — who did what and when.
• Templates —Onboarding template configurations (department, job title, license SKU IDs, group IDs).

If an attacker gained full access to our database, they would find tenant IDs, email addresses, portal roles, and audit log entries. They would not find:

• Access tokens —Stored only in encrypted browser session cookies, not in the database.
• Refresh tokens —Same — encrypted in the session JWT, never persisted server-side.
• Passwords —We never receive or store Microsoft 365 passwords.
• Client secrets —Our app's client secret is stored as an environment variable on Vercel, not in the database.

An attacker with our database alone cannot sign into your tenant, cannot call the Microsoft Graph API on your behalf, cannot reset passwords, and cannot read your users' data. The database is essentially a billing and audit ledger.

Here's the full authentication flow, step by step:

UserDesk uses delegated permissions, not application permissions. This is a critical distinction:

• Delegated —The app acts on behalf of the signed-in user. It can only do what that user is allowed to do. If the user signs out, the app has no access. This is what UserDesk uses.
• Application —The app has its own identity and can access data without a user being signed in. UserDesk does NOT use this model.

This means UserDesk has zero standing access to your tenant. When no one is actively using the portal, there are no valid tokens and no way to access your data. The app cannot "phone home" or run background operations against your tenant.

During initial setup, a Global Admin approves the following Microsoft Graph permission scopes:

• User.ReadWrite.All —Read and write user profiles (create accounts, update details, enable/disable).
• Directory.ReadWrite.All —Read and write directory data (required for license assignment and group management).
• Group.ReadWrite.All —Read and write groups (manage Teams, distribution lists, security groups).
• UserAuthenticationMethod.ReadWrite.All —Reset passwords (required for the password reset feature).

These scopes define the maximum set of actions the app can perform. Within UserDesk, the portal role system (Admin/Member/Viewer) further restricts what each individual user can do. A Viewer, for example, cannot take any write actions even though the permission scopes allow it.

Your Global Admin can revoke UserDesk's access at any time from the Azure Portal → Enterprise Applications → UserDesk → Properties → Delete. This immediately invalidates all tokens and removes the app's consent from your tenant. No data migration, no export needed — UserDesk doesn't hold any of your data.

• Hosting —Vercel (AWS-backed), with automatic HTTPS, DDoS protection, and edge caching for static assets.
• Database —PostgreSQL on Supabase with encrypted connections (SSL required), row-level isolation by tenant.
• Security headers —Every response includes X-Frame-Options (DENY), HSTS, X-Content-Type-Options, XSS Protection, Referrer-Policy, and Permissions-Policy.
• Rate limiting —Sensitive write operations (password resets, user creation) are rate-limited per IP to prevent abuse.
• Audit trail —Every action is logged with the actor, target, timestamp, and metadata. Entries are immutable.
• Session security —Session cookies are HttpOnly, Secure, SameSite=Lax. Tokens are encrypted in a signed JWT.

If you have security questions or need additional detail for your compliance review, contact us at hello@getuserdesk.com. We're happy to walk through the architecture with your security team.