University of Tokyo OAuth Scopes

OAuth 2.0 probed

University of Tokyo 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 EducationEducationJapanPublic Research UniversityResearch DataResearch RepositoryLibraryDigital ArchivesIdentity FederationIIIFOAI-PMHOpen AccessMetadata

Scopes: 0 Flows: Method: probed

Scopes (0)

University of Tokyo 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.

There are no OAuth 2.0 scopes to record. No OAuth authorization server, token endpoint or scope vocabulary exists on any University of Tokyo host — /.well-known/oauth-authorization-server and /.well-known/openid-configuration are absent, and every public surface answers unauthenticated. This file exists to record that absence explicitly rather than leave the slot empty and let a reader infer a gap in the profile. The nearest equivalent to a scope model at this institution is SAML attribute release through GakuNin — an IdP decides which attributes (eduPersonPrincipalName, eduPersonAffiliation, eduPersonScopedAffiliation, and so on) it releases to which Service Provider. That is an authorization boundary, but it is a federation policy negotiated between entities, not a scope a developer can request. The three University of Tokyo entities and their endpoints are recorded in authentication/university-of-tokyo-authentication.yml.

📄 Provider scope reference:

Source

OAuth Scopes

generated: '2026-08-19'
method: probed
source:
  - https://repository.dl.itc.u-tokyo.ac.jp/oai?verb=Identify
  - https://repository.dl.itc.u-tokyo.ac.jp/api/records/
  - https://da.dl.itc.u-tokyo.ac.jp/portal/help/api
  - https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml
oauth2: false
scopes: []
note: >-
  There are no OAuth 2.0 scopes to record. No OAuth authorization server, token endpoint or
  scope vocabulary exists on any University of Tokyo host — /.well-known/oauth-authorization-server
  and /.well-known/openid-configuration are absent, and every public surface answers
  unauthenticated. This file exists to record that absence explicitly rather than leave the slot
  empty and let a reader infer a gap in the profile.

  The nearest equivalent to a scope model at this institution is SAML attribute release through
  GakuNin — an IdP decides which attributes (eduPersonPrincipalName, eduPersonAffiliation,
  eduPersonScopedAffiliation, and so on) it releases to which Service Provider. That is an
  authorization boundary, but it is a federation policy negotiated between entities, not a scope
  a developer can request. The three University of Tokyo entities and their endpoints are
  recorded in authentication/university-of-tokyo-authentication.yml.
authorization_model:
  public_read:
    surfaces:
      - OAI-PMH (both endpoints)
      - IIIF Presentation manifests and Image API
      - Archives Portal item representations (_format=json|csv|bix)
      - Repository /api/records/
    control: >-
      Open to anyone. The Archives Portal restricts what it exposes at the data layer instead —
      only material for which reuse permission was obtained is served through the APIs, per the
      university's own documentation. Per-record access is carried in the JPCOAR accessRights
      field ("open access" on every sampled record).
  federated:
    surfaces:
      - UTOL learning management system
      - HPC Portal (Wisteria / Miyabi)
      - STEP10 course registration system
      - Licensed library resources
    control: SAML 2.0 attribute release via the university's GakuNin-registered Shibboleth IdPs.
  edge_denied:
    surfaces:
      - https://da.dl.itc.u-tokyo.ac.jp/portal/search
    control: >-
      Apache-level HTTP 403 to external automated clients regardless of User-Agent. Not an
      authorization scheme — no credential exists that would lift it.