LinkedIn OAuth for On-Call Identity
An odd choice on the face of it. Here's why LinkedIn ended up being the cleanest identity provider for on-call notifications, and how routing rules now use it to find the right human at the right time.
Why LinkedIn at all
The honest answer: it was the identity provider every engineer at every customer already had, with a verified email, a real name, and a stable URL we could use as a permanent ID. SSO providers like Okta or Azure AD assume you're inside a single tenant; on-call routing across consultancies, contractors, and acquired teams crosses tenants constantly. LinkedIn is the only identity layer that survives the org-chart churn.
The second reason: the verified-name signal. When Nova schedules a comms update mentioning who's on call, having a verified human name on the message is meaningfully better than a Slack handle nobody recognises. We A/B tested this with two beta tenants, incident comms naming the on-call person by their LinkedIn-verified name had a 19% higher acknowledgement rate from cross-team responders.
What we tried first
The first version of identity used Slack user IDs. It worked inside one workspace and broke the moment you crossed orgs. Multi-org deployments, agencies, MSPs, joint operations between an acquired company and the parent, couldn't share a routing rule without keeping two parallel user-ID maps in sync.
The second version used GitHub. Better, because GitHub IDs are global. Worse, because not every on-call engineer has a GitHub account they use day-to-day, and the email-on-GitHub field is optional. We had teams where 20% of on-call engineers either had no public email or had set it to a personal address they didn't read.
The third version used corporate email + DNS verification. This worked but was painful, every on-call user had to do a per-domain verification dance, and contractors with shared mailboxes got stuck. The friction killed adoption.
LinkedIn fixed all three. Engineers already have an account. The OAuth flow is a 15-second click. The verified email and name come back in the token. Multi-org works because LinkedIn IDs are global. We migrated existing identity records from email to LinkedIn URN over a two-week window.
The OAuth scope
We request the smallest scope that does the job, openid, profile, email. That returns the user's LinkedIn URN, name, profile picture URL, and verified email address. We don't request connection lists, post-on-behalf permissions, or anything that touches the user's social graph. The connect button shows the exact data the consent page will return.
The token itself we don't store long-term. We exchange it once for the profile data, persist the verified URN and email in our identity store, and discard the access token. Re-authentication every 90 days renews the verified status. If a user changes their LinkedIn email, the next renewal picks it up automatically.
Routing by identity
Routing rules can now reference users by LinkedIn URN. A rule like "page the platform on-call" resolves through the schedule, finds the URN of whoever's on rotation, and drives notifications based on that single key. Slack, email, and SMS destinations are all looked up from the URN, change the URN once and every channel updates.
The routing engine also uses the verified name during incident comms. When the schedule says "Alex is on call from 02:00 to 10:00 UTC," the comms drafts include "Alex Chen, on-call engineer" rather than a Slack handle. Customers and cross-team responders can verify the human; engineers feel less like an anonymous handle. Small detail; meaningful.
Privacy and opt-out
Three guarantees. First, the LinkedIn integration is opt-in per user, not per tenant, a tenant admin can't force-enable it for the whole team. Second, you can revoke at any time from the user-settings page; we delete the URN and verified email within an hour. Third, we never publish your LinkedIn URN, profile picture, or any LinkedIn-derived metadata externally without an additional explicit consent step.
For tenants in regulated industries that can't use a public identity provider for compliance reasons, the older SSO and DNS-verified email paths still work. LinkedIn is the recommended path for everyone else because it's the lowest-friction one we've found, but it's not the only path. The identity store is provider-agnostic; rules don't care which provider issued the URN.