Outlook SSO via Auth0

1) Components & Hosting Locations

Rox does not host any Microsoft infrastructure. Your Entra tenant remains authoritative for user authentication.

2) Microsoft Entra (Azure AD) Application Details

• App Type: Multi-tenant enterprise application used exclusively for OIDC/OAuth2 sign‑in.
• Auth Protocols: OpenID Connect (OIDC) + OAuth 2.0 via Auth0 Enterprise connection.
• Grant Types: Authorization Code with PKCE.
• Requested Microsoft Graph Scope: User.Read (delegated).
• Consent Model: Standard user consent or tenant admin consent (as per your policy).
• Tokens: Short‑lived ID/Access tokens returned to Auth0, which issues an application session for Rox. No long‑lived refresh tokens are stored by Rox for SSO.

Directory Objects Accessed (read‑only):

• User basic profile fields (e.g., displayName, givenName, surname, userPrincipalName/email, objectId).
• No group membership, no mailbox, no calendar, no files, no directory write.

3) Authentication Flow (High‑Level)

1. User clicks “Continue with Microsoft” on Rox sign‑in.
2. Browser is redirected to Auth0 → Microsoft Entra authorization endpoint.
3. User authenticates with your Entra tenant (MFA/Conditional Access as configured by you).
4. Entra issues ID/Access tokens to Auth0 for the scope.
5. Auth0 validates tokens, maps identity to a Rox user, and creates a secure session.
6. The user is redirected back to Rox as an authenticated session.

    Rox(Browser) --> Auth0[Enterprise Conn]
    Auth0 --> MicrosoftEntra[Microsoft Entra Tenant]
    Rox <-- ID/Access tokens (User.Read) <-- MicrosoftEntra

4) Data Handling & Privacy

• Personal Data Used: Basic identity attributes required for SSO (name, email/UPN, Entra object ID, tenant ID).
• PII Minimization: Only attributes necessary for account identification and access control are stored.
• Data Residency: Rox app workloads are hosted in the United States (see §1).
• Retention: Identity attributes retained only for account lifecycle, auditing, and access management.
• Deletion: On request or account closure, user records can be deleted per Rox data lifecycle processes.

5) Creating an allowlist of users

• Microsoft Entra Admins can go into Enterprise Apps in the Entra portal and look for the Rox 365 Integration.
• Go to Properties > Ensure that Assignment Required is set to Yes.
• Go to Users & Groups > Provide access to a certain set of users and groups. Any user outside of those mentioned here will not be able to log in to Rox.

6) Security Controls

• Transport: TLS 1.2+ for all in‑transit communications.
• Encryption at Rest: Managed encryption for data stores (e.g., AES‑256).
• Session Security: Short‑lived tokens; HttpOnly/SameSite cookies; CSRF protections on OIDC callback.
• Account Security: Your tenant’s Conditional Access, MFA, and risk policies remain in force—Rox defers to your Entra controls for primary auth strength.
• Least Privilege: User.Read only; no write or directory‑level scopes.

7) Customer Action Checklist (IT/Security)

1. Create/Approve Enterprise Application connection for Rox in Auth0 ↔ Entra (standard Enterprise connection).
2. Grant/Approve delegated scope (user or admin consent per your policy).
3. Allow the app for your users/groups per your Entra assignment model.
4. Confirm callback/redirect URIs provided by Rox’s Auth0 tenant are allowed (Rox will supply exact URIs separately).
5. Verify Conditional Access/MFA behavior meets your standards.

8) Summary

• Purpose: SSO only; no access to Microsoft 365 data.
• Permissions: Delegated User.Read only.
• Hosting: Vercel (US), AWS us‑east‑2 (US), Auth0 (US).
• Data: Minimal profile attributes to identify the user; encrypted in transit/at rest.
• Controls: OIDC/OAuth2 via Auth0; MFA/CA enforced by your Entra tenant; least‑privilege access.

For any additional vendor security questionnaires or to receive exact redirect URIs, JWKS, or metadata (OIDC discovery, signing algorithms), contact Rox Support.