Tum Authentication

generated: '2026-08-19'
method: probed
source: >-
  Live probes on 2026-08-19 of every surface attributed to Technical University of Munich, plus
  the security schemes declared in the contracts saved under openapi/. Each entry carries the
  operator of the thing it describes — an institution's authentication story is mostly its
  vendors' authentication stories, and this artifact refuses to blur the two.
surfaces:

- surface: TUM Campus App Backend API
  x-operator: institution
  base_url: https://api.tum.app/v1
  scheme: none
  detail: >-
    The generated contract declares no securityDefinitions and no global security requirement, and
    the read operations answer unauthenticated (GET /v1/news/sources 200, GET /v1/student_clubs 200,
    GET /v1/dish/rating/allDishTags 200). Write operations (POST /v1/device, POST /v1/feedback,
    POST /v1/*/rating/new) are governed by a device registration and an in-band token carried in the
    request body rather than by a declared security scheme, so no scheme is discoverable from the
    contract. This is a real contract gap, not a finding of "open write access".
  evidence:
  - url: https://api.tum.app/v1/news/sources
    status: 200
  - url: https://api.tum.app/swagger/swagger.json
    status: 200

- surface: NavigaTUM
  x-operator: institution
  base_url: https://nav.tum.de/api
  scheme: none
  detail: >-
    Fully unauthenticated read API. Search, location lookup, maps and calendar answer without
    credentials. The feedback endpoints use a short-lived token issued by GET /api/feedback/get_token
    as an anti-abuse measure; it is not an identity credential and grants no user context.
  evidence:
  - url: https://nav.tum.de/api/search?q=mi
    status: 200
  - url: https://nav.tum.de/api/status
    status: 200

- surface: eat-api
  x-operator: tenant
  base_url: https://tum-dev.github.io/eat-api
  scheme: none
  detail: >-
    Static JSON files on GitHub Pages. No authentication exists or could exist.
  evidence:
  - url: https://tum-dev.github.io/eat-api/enums/canteens.json
    status: 200

- surface: TUMonline (CAMPUSonline)
  x-operator: tenant
  base_url: https://campus.tum.de/tumonline
  scheme: oauth2
  openid_configuration: >-
    https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/.well-known/openid-configuration
  detail: >-
    TUM's student information system runs CAMPUSonline, and its Keycloak realm publishes a complete
    OpenID Connect discovery document on TUM's own campus.tum.de host. The realm is named
    CAMPUSonline, not TUM — the contract shape is the vendor's; the deployment, the users and the
    data are TUM's. This is the operator distinction this pipeline exists to keep straight, so it is
    recorded as a tenant relationship and NOT saved as a TUM contract.
  endpoints:
    issuer: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline
    authorization: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/protocol/openid-connect/auth
    token: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/protocol/openid-connect/token
    userinfo: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/protocol/openid-connect/userinfo
    jwks: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/protocol/openid-connect/certs
    introspection: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/protocol/openid-connect/token/introspect
    end_session: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/protocol/openid-connect/logout
    dynamic_registration: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/clients-registrations/openid-connect
  grant_types:
  - authorization_code
  - client_credentials
  - implicit
  - password
  - refresh_token
  - urn:ietf:params:oauth:grant-type:device_code
  - urn:ietf:params:oauth:grant-type:token-exchange
  - urn:ietf:params:oauth:grant-type:uma-ticket
  - urn:openid:params:grant-type:ciba
  pkce_methods:
  - plain
  - S256
  notes:
  - >-
    The realm still advertises the implicit and resource-owner-password grants alongside
    authorization_code + PKCE. Both are discouraged by OAuth 2.1 / BCP 225.
  evidence:
  - url: https://campus.tum.de/tumonline/co/public/sec/auth/realms/CAMPUSonline/.well-known/openid-configuration
    status: 200

- surface: TUM Shibboleth Identity Provider
  x-operator: institution
  base_url: https://login.tum.de/idp
  scheme: saml2
  detail: >-
    SAML 2.0 / Shibboleth IdP, DFN-AAI registered, eduGAIN reachable, asserting scope tum.de and
    carrying REFEDS Research & Scholarship plus SIRTFI and SIRTFI2 assurance certifications. This is
    the one authentication surface a university operates by definition, and it is machine-readable.
  evidence:
  - url: https://login.tum.de/idp/shibboleth
    status: 200