Stanford University OAuth Scopes

OAuth 2.0 derived

Stanford 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 EducationEducationResearchUnited StatesCaliforniaPrivate Research UniversityAssociation of American UniversitiesResearch RepositoryCourse CatalogIdentity FederationLibraryDigital RepositoryArtificial IntelligenceIIIF

Scopes: 0 Flows: Method: derived

Scopes (0)

Stanford 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

name: Stanford University — authorization scopes
description: >-
  Scope inventory for Stanford's institution-operated API surfaces. The honest finding is that
  Stanford declares NO OAuth or fine-grained scopes anywhere in its five first-party contracts:
  authorization is coarse — a bearer token, a client certificate, or an issued API key grants
  the whole service. What Stanford does have instead is a privilege model expressed as its own
  Registry web service, and a Shibboleth attribute release policy at the identity layer.
generated: '2026-08-19'
modified: '2026-08-19'
method: derived
source: >-
  openapi/_original/*.yml security + components.securitySchemes (no oauth2 flows present),
  https://uit.stanford.edu/developers/apis/privilege, https://idp.stanford.edu/metadata.xml
x-operator: institution
oauth_scopes:
  declared: false
  method: derived
  note: >-
    No securityScheme of type oauth2 or openIdConnect appears in any of the five contracts.
    bearerAuth is declared with `scheme: bearer` and no scope list, so `security: [{bearerAuth: []}]`
    is authorization at service granularity.
  checked:
    - openapi/_original/stanford-sdr-api-openapi.yml
    - openapi/_original/stanford-dor-services-api-openapi.yml
    - openapi/_original/stanford-technical-metadata-api-openapi.yml
    - openapi/_original/stanford-preservation-catalog-api-openapi.yml
    - openapi/_original/stanford-suri-api-openapi.yml
authorization_model:
  - id: mais-privilege-service
    name: MaIS Registry Privilege API
    method: searched
    source: https://uit.stanford.edu/developers/apis/privilege
    note: >-
      Stanford externalizes authorization as its own API rather than as scopes on other APIs.
      The Privilege web service answers "what authority does this person hold", and the
      Workgroup web service answers "who is in this group" — the two together are Stanford's
      campus-wide entitlement model. This is an institution-designed pattern, not a vendor's.
    evidence:
      - url: https://uit.stanford.edu/developers/apis/privilege
        status: 200
      - url: https://uit.stanford.edu/developers/apis/workgroup
        status: 200
  - id: shibboleth-attribute-release
    name: Shibboleth attribute release
    method: probed
    source: https://idp.stanford.edu/metadata.xml
    note: >-
      At the federation layer, authorization is carried by released SAML attributes scoped to
      stanford.edu (shibmd:Scope). The metadata declares the IdP side; the attribute release
      policy itself is not published.
    evidence:
      - url: https://idp.stanford.edu/metadata.xml
        status: 200
  - id: ai-gateway-key
    name: AI API Gateway key
    method: searched
    source: https://uit.stanford.edu/service/ai-api-gateway
    note: >-
      Authorization is per-key and per-PTA (billing account), with usage queryable by key. No
      scope vocabulary is published; a key is all-or-nothing against the models in the gateway.
    evidence:
      - url: https://uit.stanford.edu/service/ai-api-gateway
        status: 200

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/stanford-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.