Jitsi Google Calendar, Outlook and Dropbox integrations

Each OAuth app behind the Jitsi Google Calendar, Outlook and Dropbox integrations needs a named technical owner and a named business owner before anyone creates it. The Jitsi web integrations guide has you create a Google Cloud OAuth client with the Google Calendar API and YouTube Data API v3 enabled, register a Microsoft app with Microsoft Graph delegated permissions such as Calendars.Read and Calendars.ReadWrite, and create a Dropbox API app with app folder access. Each of those three registrations carries an owner account, a client secret or app key, a consent configuration and renewal duties. If nobody is named for those four things, the integration tends to break quietly when a secret expires or a consent screen changes, and nobody knows who to call.

The technical owner is the engineer who maintains the deployment's config.js settings, the redirect URIs such as /static/msredirect.html and /static/oauth.html, and the values stored for the app. The business owner is the person who decides which users and calendars the integration serves and who signs off on its scope, such as whether calendar write access is needed or read access is enough. Write both names into the integration record. A reasonable starting point is to ask the Jitsi platform team to propose the technical owner and the business owner who approves each permission change.

Register each app under a dedicated service or shared administrative account, not under a personal mailbox or a personal Dropbox login. When an employee leaves or changes roles, a personal registration can lock the organization out of its own app, and transferring ownership later can require the original account holder's cooperation. Confirm with your identity team which account is used, whether it is protected by multi-factor authentication, and who holds recovery methods. Keep the account's group memberships and access reviews in the same process you use for other administrative accounts.

Record where each credential lives. For every app, note the registering account, the location of the client secret or app key, the secret's expiry date where the provider shows one, the redirect URIs configured, and the people who can read or rotate the value. Store the secret in your approved secrets manager rather than in a shared document or a chat thread, and make sure the deployment reads it from there. Rotation is a planned task: assign it to the technical owner with a reminder set well before expiry, and test the integration after each change.

Google and Microsoft both apply consent and verification rules that can require an administrator. Depending on the scopes requested and your tenant settings, a Google Workspace administrator or a Microsoft Entra administrator may need to grant consent for the organization or approve the app before users can connect their calendars. Ask your identity team early which consent path applies to the scopes listed in the guide, whether an app review is needed, and whether the tenant restricts user consent. Include the identity team in the ownership discussion so that administrator approval and renewal do not become a blocker on launch day.

The redirect URI is the address your identity provider sends the browser back to after a user approves access. The provider completes that handoff only when the address matches one registered on the app, character for character. For this integration, the Microsoft app redirects to https://yourdomain.com/static/msredirect.html, and the Dropbox app uses the /static/oauth.html path, which you set in the deployment's config.js. Both paths live on your Jitsi domain, so that domain is part of your identity configuration as well as your meeting service. Before go-live, confirm the exact redirect entries your Google Cloud OAuth client needs against the Jitsi handbook's web integrations guide, and record them beside the Microsoft and Dropbox values.

Any difference between the registered value and the URL the browser actually uses breaks sign-in. A changed hostname, a switch from https to http, a non-default port, or a path that drifts from msredirect.html or oauth.html all produce a mismatch. The failure usually appears at the provider as an error page or a stalled consent step, so the team may check Jitsi first while the cause sits in the app registration. A common case is a staging host registered under production settings. Illustrative example: staging is added to the production Microsoft app, so test sign-ins are recorded against production, and when staging is retired the production app still lists a host nobody maintains. Confirm with each provider how it handles callbacks to unregistered hosts before you rely on that behavior.

Keep one registered redirect per environment. Production, staging and any test deployment each need their own domain, their own provider app or at least their own redirect entry, and their own config.js values. Do not keep retired hostnames in the list as a precaution, because every extra entry is an address that can receive a sign-in response. Name one owner for each provider console, usually the person who created the Microsoft app, the Google Cloud project or the Dropbox app, and make that owner responsible for adding, changing and removing entries. Review the lists on a fixed schedule and again whenever an environment is decommissioned.

Document every change to the domain or certificate, including the date, the reason, the new URI and each provider app it touched. A certificate renewal that keeps the same hostname usually leaves the redirect alone, but a new hostname, a new domain or a move to a different proxy can change what the browser sends back. A certificate change can also disable sign-in silently: the meeting itself still loads, while the consent step fails for calendar and Dropbox integrations. Test Google Calendar sign-in, Outlook sign-in and a Dropbox recording upload after each change, and keep those results in the same record. Ask each provider how long a removed entry stays active, and plan the cutover window around that answer.

Every calendar and recording integration should pass a short, written test sequence before anyone is told it works. Calendar sign-in, YouTube-linked options and Dropbox uploads each depend on a separate OAuth app, redirect URI and set of permissions, so a single successful meeting does not prove the integrations are healthy. Plan the test as a checklist you run per integration, and keep the results where a reviewer can find them. Start each integration with a dedicated test account rather than a senior executive's mailbox or a shared operations login. For Google Calendar, sign in through the Jitsi calendar integration and confirm that upcoming calendar entries load in the meeting interface. For Outlook, repeat the same sign-in and check that entries from the Microsoft calendar appear, which confirms the Microsoft app's redirect URL and delegated Calendars permissions are working. Use a test calendar with a few known entries so the expected result is obvious to the person running the check. If your deployment has YouTube-linked options enabled, test them separately from calendar sign-in, because they rely on the YouTube Data API v3 being enabled in the same Google Cloud project. Create a test meeting, select the YouTube option, and confirm the broadcast option is offered and completes. For Dropbox, start a test recording in a room you control and confirm the file lands in the designated test folder under the app folder access you configured. Check that the stored file opens and that the Dropbox app key and redirect URI in config.js match the registered app. Confirm the exact steps with the current Jitsi web integrations guide for your release, because menu labels and settings can change.

Repeat the full sequence after every Jitsi upgrade and after every certificate renewal. A renewed certificate can change the trust chain or the domain that the redirect URLs depend on, and an upgrade can change config.js or the static redirect pages. Treat a failed regression check as a blocker for the change, not a note for later. Keep the redirect URLs registered with Google, Microsoft and Dropbox in your change record, so a reviewer can see that the registered values still match the live domain after the change. Record the same evidence every time so an auditor or security reviewer can follow it without asking questions. For each test, capture who performed it, the Jitsi build tested (use the build identifier from your deployed release, not a version you assume), the integration and test account used, the date, the expected result, the actual result and any defect reference. Store screenshots or exported logs only where they contain no tokens, personal calendar content or recording data. A short table in your change system is usually enough. Separate the tester from the approver where your change process requires it. The person who runs the Dropbox upload test should not be the only person who signs off that the upload folder and app folder access are correct. Ask your DeployOpen team, or your own platform team, to confirm the evidence format before the first production test, so the record matches your control framework. Keep the test account credentials in your secrets store, and confirm with each provider how test accounts are handled under your tenant policies.