Carnegie Mellon University · OAuth Scopes

Carnegie Mellon University OAuth Scopes

OAuth 2.0 probed

Carnegie Mellon University uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.

This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.

UniversityHigher EducationEducationUnited StatesPrivate Research UniversityResearchEpidemiologyPublic HealthCybersecurityVulnerability DisclosureScholarly PublishingInstitutional RepositoryIdentity FederationOpen AccessOpen Data
Scopes: 0 Flows: Method: probed

Scopes (0)

Carnegie Mellon University implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.

📄 Provider scope reference:

Source

OAuth Scopes

Raw ↑ 
generated: '2026-08-19'
method: probed
source: >-
  Live probes 2026-08-19 of https://api.delphi.cmu.edu/epidata and https://kb.cert.org/vuls/api,
  plus the SAML metadata at https://login.cmu.edu/idp/shibboleth.
provider: Carnegie Mellon University
providerId: carnegie-mellon-university
summary:
  oauth_scopes_published_by_the_institution: 0
  reason: no_oauth_surface_operated_by_the_institution
description: >-
  Carnegie Mellon University operates no OAuth 2.0 or OpenID Connect authorization server on a
  public, institution-owned API surface, so there are no institution-published scopes to record.
  Both institution-operated public APIs — Delphi Epidata and the CERT/CC Vulnerability Notes API
  — are anonymous and read-only, with no scoped authorization layer of any kind. This file exists
  to state that absence explicitly rather than leave it ambiguous; it is a REWARD-ONLY artifact and
  no scope has been invented to fill it.
scopes: []
authorization_model_in_use_instead:
- model: SAML 2.0 attribute release
  operator: institution
  surface: https://login.cmu.edu/idp/shibboleth
  detail: >-
    CMU's authorization boundary for federated services is SAML attribute release through Web
    Login, governed by the InCommon Research & Scholarship entity category rather than by OAuth
    scopes. R&S commits the IdP to releasing a defined baseline attribute bundle (eduPersonPrincipalName,
    mail, displayName / givenName + sn, eduPersonScopedAffiliation) to R&S-tagged service
    providers. That is the closest thing CMU publishes to a machine-readable permission
    vocabulary, and it is a federation profile, not a scope list.
  evidence:
    url: https://login.cmu.edu/idp/shibboleth
    status: 200
previously_recorded_and_removed:
- source: figshare OAuth 2.0
  operator: vendor
  detail: >-
    The 2026-06 profile carried a scopes file derived from the figshare v2 OpenAPI. Those scopes
    are figshare's product, published for every figshare customer, and were credited to CMU
    because the spec sat in CMU's repo. Removed 2026-08-19 under the university pipeline's
    operator rule.
maintainers:
- FN: Kin Lane
  email: kin@apievangelist.com

Work with this as data

Every scope set here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for oauth scopes

4 MCP tools reach this
  • find_scopesBrowse and filter every scope set in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This scope set 
curl "https://apis.io/api/v1/scopes/carnegie-mellon-university-scopes"
All oauth scopes 
curl "https://apis.io/api/v1/scopes?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have.