Docs
Search K

Appearance

Third-Party Accounts ​

Third-Party Accounts let MinuteView integrate with external platforms per user. Unlike Service Accounts (which are shared, system-level credentials), Third-Party Accounts store the application details once and then require each individual user to authenticate with their own login. Their tokens are then securely stored on the server for reuse.

How They Differ from Service Accounts ​

AspectService AccountsThird-Party Accounts
PurposeSystem-wide, shared credentialsUser-specific authentication against an external system
Who logs in?No one; credentials are pre-entered and reusedEach user must sign in once to authorise MinuteView
StorageKeys/secrets saved once by an adminUser tokens saved per user (server-side)
Typical UseAI Model (AI assistant), SQL, GemBox, etc.Microsoft Graph, Google, other OAuth-based services

Network Requirements (OAuth) — Server Outbound Access ​

Third-Party Accounts are OAuth-based. Although each user signs in through their own browser, the token exchange and all ongoing token refresh happen on the MinuteView server, which calls the provider's authentication and API endpoints directly. If your organisation restricts outbound traffic from the server, you must whitelist the provider's domains or these accounts will fail — often after a successful-looking browser sign-in, once the first token needs refreshing.

Whitelist the following for HTTPS (port 443) outbound from the MinuteView server, per provider you use:

ProviderDomains to whitelist
Microsoftlogin.microsoftonline.com, graph.microsoft.com
Googleoauth2.googleapis.com, www.googleapis.com
Autodeskdeveloper.api.autodesk.com, api.userprofile.autodesk.com
Bluebeamapi.bluebeam.com (US), api.bluebeamstudio.com.au (AU), api.bluebeamstudio.eu (EU)

Full per-provider detail

Each provider's own setup page (linked in the sidebar) has a Network Requirements section with the exact domains and what each is used for. The Microsoft OAuth page is a good reference for the pattern.

Creating a Third-Party Account Definition ​

  1. Navigate to Console → Third-Party Accounts.

  2. Click New.

  3. Select the Provider/Type (e.g., Microsoft).

  4. Enter the required fields for that provider. For Microsoft, you typically provide:

    • Client ID
    • Client Secret
    • Tenant ID(Other providers may require different fields—follow the on-screen prompts.)

  5. Give it a clear Name (e.g., Microsoft 365 Prod).

  6. Save.

This creates the app definition MinuteView will use to request user consent.

User Sign-In Flow ​

Once a Third-Party Account is defined:

  1. A user performs an action that needs that provider (e.g., access Microsoft files).
  2. MinuteView prompts the user to sign in with their own credentials.
  3. Upon successful sign-in/consent, a token is issued and stored securely on the server, associated with that user.
  4. Future calls to that provider use the stored token—no need to re-authenticate until it expires or is revoked.

Managing Third-Party Accounts ​

  • Edit Definition: Update client secrets/IDs if they rotate or change. Users may need to re-consent afterward.
  • Revoke Tokens: An admin can clear a user’s stored token if necessary (e.g., security incident).
  • Delete Definition: Remove unused providers after confirming nothing depends on them.

Best Practices ​

  • Name Clearly: Include environment and scope (e.g., Microsoft-Graph-Prod).
  • Rotate Secrets: Follow the provider’s rotation policies and update MinuteView promptly.
  • Limit Scopes: Configure the external app with the minimum permissions required.
  • Communicate to Users: Let users know they must sign in once to enable features tied to that provider.

See Also ​

  • Service Accounts – For system-level integrations (e.g., AI Model, Microsoft Azure).
  • User Management – Roles and permissions controlling who can use which integrations.
  • Global Settings – Ensure core URLs and modules are enabled so integrations work as expected.

Tentech