OAuth Scopes and Least Privilege in EdTech API Connections

K-12 districts aren't connecting a handful of tools to their student data systems. They're connecting thousands, and that number keeps climbing every school year. Each one of those connections is a live OAuth authorization, sitting quietly in the background with its own bundle of permissions, and most districts have no real idea how many of those bundles they're carrying or what's inside them.

Evelyn Learning's analysis of district software inventories found K-12 districts run an average of 2,739 different software applications. Only 57% get actively used. Close to half the tools sitting in a district's tech stack are dead weight that nobody bothered to disconnect, each one still holding whatever access it was granted the day someone clicked "allow."

This isn't a case of a few IT admins dropping the ball. It's structural. When you multiply thousands of integrations by inconsistent scope requests and zero revocation discipline, the math turns bad fast. Add in the fact that teachers and coordinators authorize plenty of these tools on their own, outside any IT review process (call it shadow SaaS, or just call it Tuesday), and you get a system where manual oversight simply isn't possible. The only lever left that actually scales is the design of the authorization mechanism itself. That's what this piece is about.

What OAuth scopes actually do — and what they don't do on their own

OAuth 2.0 answers "what can this app do," not "who is this person." That distinction trips people up constantly, so it's worth saying plainly: OAuth is authorization, not authentication. Scopes are the strings inside that authorization that spell out exactly what a client app is asking permission to do, whether that's reading a class roster or writing grades back into a system of record.

Here's a detail that surprises people outside the API world: OAuth 2.0 doesn't define standard scopes the way OpenID Connect does for identity. Every API gets to invent its own scope names and structure. A "read" scope in one EdTech platform might mean something totally different in another, and the client app has to know the exact scope strings in advance. There's no universal dictionary here, which is part of why scope sprawl gets messy so quickly.

When scopes are designed well, they're the actual mechanism that enforces least privilege at the API layer. A token scoped down to roster.read can only ever touch the roster, nothing else, no matter what else lives on that server. That's the theory, and it holds up when implemented carefully.

Scopes don't do everything on their own, though, and this is where a lot of the danger hides. They don't expire when a vendor contract ends. They don't revoke themselves when the teacher who approved them leaves the district. Nothing in the spec stops a user from granting an app far more than it actually needs to do its job. The OAuth spec doesn't even require a scope parameter at all, technically speaking, an app can request a token with no scope specified, which is legal but about as far from least privilege as you can get.

Token lifecycle makes this worse. Grants persist until someone actively goes and revokes them. They survive password resets. They survive the employee who set them up walking out the door for good. A scope granted once is, for all practical purposes, permanent unless a human steps in.

1EdTech's LTI 1.3 standard, a widely adopted framework for EdTech tool connections, is built on OAuth 2.0, OpenID Connect, and JSON Web Tokens, with a recommended token expiry of just one hour. That's a smart default, and it limits how long a stolen token stays useful. Token freshness and scope are two separate problems, though. A token that expires in an hour but was scoped to read and write every student record in the system just re-authenticates itself back into full access, hour after hour, forever.

How over-scoping becomes the default in EdTech environments

Ask any developer why their app requests broad permissions and you'll usually get some version of the same answer: it's just easier. Requesting "full access" up front covers every future feature they might build and skips the annoying re-authorization prompt down the line. Nobody wants to ship a v2 that suddenly asks users to approve five new permissions.

The people approving these requests aren't reading the fine print either. A special education coordinator clicking through the consent screen for an IEP tracking tool isn't parsing scope strings, she's trying to get a tool working before her next meeting. The gap between what an app asks for and what it actually needs is invisible at the exact moment someone hits "allow."

There's a real tension in how granular scopes should be. Make them too fine-grained, and users get hit with a wall of permissions on the consent screen, tune out, and approve the whole batch anyway. Make them too coarse, and a single scope grants far more than any one workflow calls for. The industry's best answer is a naming pattern like resource.operation, so roster.read and grades.write actually mean something legible to a human glancing at them. That only works if the API designer built scopes that way in the first place, though, and plenty haven't.

In schools specifically, the authorizing party is often nowhere near the IT department. A teacher connects a reading app. A coordinator approves an assessment tool. Each of those creates a scope grant that IT staff may never lay eyes on. These grants don't just sit there quietly, they accumulate. An app authorized during a 2021 pilot, with write access to student records, can still be sitting there years later after the pilot wrapped, the vendor got acquired, and the teacher who approved it moved to a different district entirely.

Obsidian Security found that 97% of non-human identities carry excessive privileges, and 85% of organizations lack full visibility into third-party vendors connected through OAuth apps. Put those two numbers together and you get the exact recipe for over-scoping: broad requests approved on autopilot, never revisited, never revoked. That's not an isolated slip-up here and there. It's the system working exactly as poorly as it's designed to.

What audited app catalogs show about real-world scope requests

Offroad's OAuth research project, OhAuth, audited 2,890 public OAuth app listings in June 2026, split between 1,595 listings on Google Workspace Marketplace and 1,295 on GitHub Marketplace. Combined, those apps report an install footprint of at least 4.39 billion.

The findings aren't subtle. 918 apps, 32% of everything audited, carry at least one red flag: scopes wider than the app's stated purpose, AI features with write access baked in, threat-intel flags tied to the publisher's domain, or a publisher website that's just plain dead. Among those, 677 apps request at least one permission that goes beyond what the app claims to do, covering a combined install base of 1.82 billion. And 266 of those apps reach into Google Drive with off-purpose access at the highest permission tier, touching 1.26 billion installs.

Offroad's CTO flagged the pattern that matters most here: roughly 90% of the flagged cases in Google Workspace aren't random overreach. They're "right category, too much access." An app built to grade quizzes doesn't need to touch every file in Drive, but it asks anyway, because scoping down later means writing more code and asking users to re-approve. That's the exact failure mode scope design exists to prevent, and it's showing up in the vast majority of cases at scale.

Google Workspace is widely deployed across K-12 districts, so these numbers map onto schools about as directly as you can get. The audit covers only public marketplace listings, so the picture it offers is necessarily partial when it comes to the full range of tools districts actually deploy.

What happens when over-scoped integrations meet a breach

The PowerSchool breach, disclosed December 28, 2024, is the incident that put all of this in sharp relief. 62 million students and 9.5 million educators had their data exposed, and the intrusion ran undetected for 9 days before anyone caught it. PowerSchool serves roughly 75% of the K-12 market, which means the blast radius here wasn't an accident of bad luck. It was baked in from the start, the moment that much access sat behind a single point of failure.

Permissions like Files.ReadWrite.All or User.Read.All, sitting in the hands of a publisher nobody bothered to verify, mean one compromised token opens the door to everything behind it.

There's a quieter, growing attack vector worth naming too: OAuth consent phishing. Attackers spin up apps with consent screens that look completely legitimate. The user clicks "allow" of their own free will. The authorization system itself becomes the way in, because nothing about the process looks suspicious from the inside — no password gets stolen, no MFA gets bypassed. Security researchers have documented a rise in this kind of activity, with coordinated campaigns turning the authorization flow itself into the attack surface.

None of this needs a dramatic hacking scene to play out badly. Picture a routine access review turning up an app with full read and write access to a district's Google Drive, authorized back in 2021 by someone who left the job 18 months ago, built by a vendor that's since been bought out and quietly shut down. Three years of live, standing access, and nobody in the building knew it was there. In schools, where staff turnover runs high and teachers authorize tools independently, this exact scenario isn't the exception. It's closer to the norm.

How FERPA, COPPA, and state privacy law interact with scope decisions

FERPA governs who can touch a student's education records, and here's the part that catches districts off guard: a third-party app holding a files.readwrite scope on a student record system is functioning as a school official under FERPA, provided it meets the legitimate educational interest test. Scope isn't just a technical setting at that point. It's a legal classification.

An app pulling in more than its stated function requires can slide right outside that legitimate educational interest exception, turning every excess permission into a potential compliance failure and not just a loose security habit.

COPPA adds another layer for anything touching kids under 13. An elementary school platform that grants a broad profile scope to some third-party app may be collecting COPPA-regulated data without anything resembling proper consent. COPPA requirements around verifiable parental consent and data minimization make scope design a direct compliance decision, not something IT quietly handles in the background.

State student privacy laws, which have proliferated across much of the country, increasingly require districts to keep an inventory of exactly what data each vendor can reach. That inventory is, functionally, just a list of scope grants dressed up in legal language. Districts that can't produce it when asked have a problem well beyond IT hygiene.

The regulatory logic here is straightforward, even if the compliance paperwork isn't: a narrower scope limits what an app can see, which limits what it can leak, which limits liability under FERPA and COPPA if something goes wrong. That's reason enough for legal and privacy counsel to sit in on the review process for any app touching student records, not just the tech team.

Designing scope requests that actually enforce least privilege

Start with the data, not the API menu. Before anyone opens a scope list, map out exactly what the app needs to do its one job, and let that answer drive the request, not the other way around.

Default to read access. Write access should require an actual documented reason tied to a real workflow, never a "we might need it later" assumption baked in at setup. Incremental authorization helps here too: request only what's needed the moment the app is first used, and ask for more later, only when the user does something that genuinely requires it.

Scope naming matters more than people give it credit for. A resource.operation pattern, roster.read, grades.write, attendance.read, makes permissions legible both at the moment of consent and months later during an audit, when someone's trying to reconstruct what an app was actually allowed to do. Balance still matters: scopes so fine-grained that users glaze over and approve everything in bulk defeat the purpose just as thoroughly as scopes too broad to mean anything.

For LTI 1.3 integrations, 1EdTech's framework already enforces short-lived tokens with that one-hour default expiry. Scope selection inside that framework deserves the same level of scrutiny as token lifetime gets, not an afterthought bolted on once the security team signs off on everything else.

From the district's side, the scope list an app requests during OAuth setup is a signal worth reading closely before approval, not after something goes wrong. An app asking for files.readwrite.all just to deliver a quiz should raise a flag at the review stage, full stop. Every scope granted needs a documented reason behind it, because that paper trail is exactly what FERPA compliance and any future breach investigation will demand. 1EdTech's emerging Edu-API standard is pushing toward more consistent, interoperable data exchange, and districts that adopt it early get a cleaner baseline to measure everything else against.

Auditing what third-party apps currently hold — and closing the gaps

Visibility comes first, and most districts don't have it. Ask an average district to list every active OAuth grant, who approved it, and what scopes it holds, and you'll get a shrug or a very long, very manual spreadsheet exercise. Building that inventory is step one, and nothing else on this list works without it.

Google Workspace and Microsoft 365 both show connected app inventories inside their admin consoles, which makes a reasonable starting point for a district-wide audit. That view only covers grants made through those platforms specifically, though. LTI connections and direct integrations, SIS connectors and rostering tools among them, live outside that view entirely and need a separate review process of their own.

Triage matters here. Prioritize apps holding write access to student records, apps tied to users no longer employed by the district, and apps from vendors whose privacy policies changed recently. Lightspeed Systems found that a majority of apps had at least one privacy policy change within a given year, which means "read it once at signup" isn't a sustainable compliance strategy.

Run what amounts to an orphaned-app test on every active grant: is the authorizing user still employed, is the vendor still operating, is the app still in active use? Fail two out of three and that grant should get revoked and re-evaluated from scratch, no exceptions carved out for convenience. Revocation shouldn't be the end of the process either — it should trigger a fresh scope review before anyone re-authorizes the tool. Does it still need everything it originally asked for? Usually the answer is no.

Closing the shadow SaaS gap means making the approved-app request process fast enough that teachers don't feel the need to route around it. Friction in that approval path is exactly what pushes staff toward unauthorized grants in the first place. Pair that with an ongoing review cadence, annual at minimum, per-semester for anything touching student records, treating scope grants as expiring by policy even when the token technically never does. Don't ignore the software nobody's using, either: Evelyn Learning found districts pay for plenty of tools they don't actively use, and every one of those still holds live scopes. An unused app with standing access is just attack surface sitting around with no upside attached.

What a defensible EdTech integration posture looks like in practice

Least privilege isn't a setting you configure once and walk away from. It has to survive staff turnover, vendor acquisitions, and the steady sprawl of new tools showing up every school year, or it stops meaning anything within a few semesters.

A posture that actually holds up rests on three layers working together. Design starts with a scope justification, not a scope list, meaning the question on the table is what the app needs to do its job, never what the API happens to offer. Authorization means no app touching student records or personal data gets approved outside a formal review, so teacher-side OAuth grants for classroom tools stay governed rather than freeform. Audit means active grants get inventoried, tracked by age, and reviewed on a set schedule, with stale grants revoked on sight rather than left alone because nobody got around to it.

None of this removes risk entirely, and nothing in OAuth was ever built to. It does turn access into something a district can actually account for, defend under a FERPA audit, and explain clearly the day a breach investigator asks the one question that matters most: who had access to this, and why.