OpenFrame is on your phone now!

OpenFrame

Connect Your Identity Provider (Advanced SSO)

IMPLEMENTATIONINTEGRATIONOPENFRAMESECURITY

Phase 8 — Integrations · Step 1

Section

June 23, 2026

Published

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Connect Your Identity Provider (Advanced SSO)

Phase 8 — Integrations · OpenFrame Onboarding

Back in Phase 1 you turned on SSO at the basic level. This guide is the admin-grade version: wiring OpenFrame directly to your own Google Workspace or Microsoft Entra identity provider with your organization's OAuth credentials, restricting who can get in by domain, and auto-provisioning accounts on first sign-in. This is how you make OpenFrame log in the same way as the rest of your stack.

Before you start

  • You need an Admin role.
  • Have access to your IdP's admin console — Google Cloud Console (for Google) or Microsoft Entra ID / Azure AD (for Microsoft) — where you can create an OAuth app and get a Client ID and Client Secret.
  • Decide which domains are allowed to sign in (e.g. yourmsp.com).

Where it lives

Go to Settings → SSO Configuration. You'll see the SSO Configurations page with:

  • A shared OpenFrame Google & Microsoft SSO option at the top — lets any account from your domain sign in via OpenFrame's shared providers, with an Auto-provision accounts toggle (creates user accounts automatically on first sign-in).
  • A list of OAuth providers — Google SSO and Microsoft SSO — each showing its Status (active/inactive), Allowed Domains, and whether it's Configured. Use Edit to set one up with your own credentials.

The shared option is the quick path; connecting your own provider (below) is the advanced, fully-controlled path.

Connect your own provider

Click Edit on Google SSO or Microsoft SSO. In the Edit SSO Configuration modal:

  1. Copy the Authorized redirect URL. OpenFrame shows the exact callback URL (e.g. https://openframe.ai/sas/login/oauth…). Paste it into your IdP's OAuth app as an authorized redirect URI. It must match exactly — authentication fails if it's off by even a trailing slash.
  2. Create the OAuth app in your IdP (if you haven't) and copy its credentials back here:
    • OAuth Client ID — paste the client ID from Google Cloud / Microsoft Entra.
    • Client Secret — paste the secret (use the eye icon to verify it pasted cleanly).
  3. Set the Domain Allowlist (optional but recommended). Toggle Auto-provision accounts from domain to automatically create OpenFrame accounts for users from your allowed domain on their first sign-in — no manual invites needed.
  4. Click Save & Enable. This saves the credentials and flips the provider from INACTIVE to active. Your team can now sign in through it.

Auto-provisioning & domain control

Two layers decide who gets an account:

  • Domain allowlist — restricts sign-in to your trusted domains, so a random Google account can't get in.
  • Auto-provision — when on, a matching user who signs in for the first time gets an OpenFrame account created automatically (handy at scale; turn it off if you'd rather invite people deliberately, per Invite Your Team, Phase 1).

Enforcing SSO

Once your provider is enabled and tested, SSO becomes the front door for your org. Verify a test user can sign in through the provider before you rely on it as the only path, so you don't lock anyone out. Keep at least one Admin able to get in while you roll it out.

Quick checklist

  • Opened Settings → SSO Configuration
  • Copied the Authorized redirect URL into your IdP's OAuth app (exact match)
  • Pasted the OAuth Client ID and Client Secret from Google/Microsoft
  • Set the Domain Allowlist and chose whether to auto-provision
  • Clicked Save & Enable and confirmed the provider is active
  • Tested a real sign-in before enforcing SSO org-wide

What's next

With identity handled, wire up the rest of your automation: API Keys & External Integrations covers generating keys for external systems and the API/webhooks that let other tools talk to OpenFrame.

Based on OpenFrame v0.9.19. SSO providers and fields evolve between releases, and exact IdP steps differ by provider — what's in your console (and your IdP's docs) wins.

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Hi all! My name is Vlad and I’ve been brought on to head the marketing team at Flamingo. Thankfully, this isn’t the first time I will be building a marketing department from scratch, so the experience should come in handy. Now it’s time to dive into the world of MSPs and find myself in this new world.

More in Phase 8 — Integrations

Related Content

Product Releases

Webinars

Case Studies

Blog Posts

Frequently Asked Questions

MSP AI Agents

Yes. In production MSP shops today, 10% to 25% of tickets close before a human opens them. Thread alone has processed 173 million tickets across 750-plus MSP partners at 96% triage accuracy, handing back 490,000-plus technician hours. Agents own the low-risk, high-volume work (password resets, MFA enrollment, known installs, onboarding and offboarding) and flag anything that touches production data or needs judgment for a human to take.
On a five-person desk, reported deployments show $78,000 to $130,000 in annual direct labor savings, roughly 30% fewer escalations, and 15% to 20% better SLA compliance. Broader MSP adoption data adds ticket handling time cut by 45% and five to 12 points of margin, all from reclaimed capacity rather than headcount cuts.

AI Safety

It can be, with governance. Keep a human in the loop on high-risk actions, log every automated step for audit, and choose platforms that keep your data yours with no vendor lock-in. Pilot on internal data first so you catch issues before client systems are involved.

About OpenFrame

OpenFrame isn't built to plug into your stack. It replaces it. Instead of duct-taping a dozen tools together (RMM, MDM, SIEM, patching, remote access, each its own login and bill), we bundle it into one unified platform: RMM, MDM, monitoring, automation, remote access, patch management, security monitoring, and ticketing, plus built-in AI copilots. So "does it integrate with X?" usually means: you won't need X anymore.

blog

Fileless malware is malicious code that runs from memory and built-in Windows tools such as PowerShell, mshta.exe or WMI instead of a file saved to disk. Because nothing is written that a scanner can hash, signature-based antivirus has nothing to match. Microsoft sorts it into three types by how much it touches the file system; the attacks small teams meet are usually scripts that run in memory and persist through the registry or a WMI subscription.
A phishing email or fake CAPTCHA gets the user to run a one-line launcher, usually a script host or an encoded PowerShell command. That launcher downloads the next stage straight into memory and runs it inside a trusted, Microsoft-signed process. To survive a reboot it stores a trigger in the registry, a scheduled task or a WMI event subscription rather than dropping a program.
A plain file scanner usually cannot, because there is no file to hash. Modern antivirus and EDR detect it through behaviour: Windows AMSI hands the decoded script to the antimalware engine at the moment it runs, behaviour monitoring matches suspicious API call sequences, and memory scanning reads the payload where it has to live. Pair that with PowerShell script block logging and Sysmon so you can see what ran and what started it.
Killing the process is not enough, because the trigger brings it back. Find the persistence first: registry autorun values and file-type handlers, scheduled tasks with encoded commands, and WMI filters, consumers and bindings in the root\subscription namespace. Remove the trigger, then the payload, then reset any credentials the machine held, and confirm with Sysmon and PowerShell logs that it did not return after a reboot.
Start with a stack audit to find where two tools hold the same data. Then ask five questions of any pane you are offered: which record is the source of truth, can you act from the pane, is there an API and a full export, which module was built last, and what leaving costs after two years.
A NOC watches availability and performance and restores service when something fails. A SOC watches for threats and contains them. They share telemetry and often share incidents, so the handoff between them needs to be written down.