Gadjah Mada University Authentication

---
generated: '2026-09-01'
method: probed
source: >-
  Live probes on 2026-09-01 of Universitas Gadjah Mada's own authentication surfaces, plus the
  institution's SAML entity descriptor retrieved directly from its Shibboleth IdP metadata
  endpoint. Every scheme below is on a host under the ugm.ac.id registrable domain.
x-operator: institution

summary:
  note: >-
    UGM is unusual for this cohort: it operates a real, first-party OAuth 2.0 / OpenID Connect
    authorization server — UGM ID — with a published OpenAPI 3.1.0 document, RFC 8414 and OIDC
    discovery documents, PKCE, token introspection (RFC 7662), token revocation (RFC 7009) and
    RFC 8693 token exchange. It ALSO runs a Shibboleth SAML 2.0 Identity Provider and a CAS
    server. Three separate institution-operated identity stacks, all self-hosted. What it does
    not have is self-service developer onboarding: there is no public client registration, no
    dynamic client registration endpoint, and no documented route for an outside developer to
    obtain a client_id. Credentials are issued internally by DTI.
  types:
  - oauth2
  - oidc
  - saml2
  - cas
  public_oauth: true
  self_serve_api_keys: false
  dynamic_client_registration: false

schemes:

- name: ugm-id-oauth2-oidc
  type: oauth2
  x-operator: institution
  description: >-
    UGM ID, the university's OAuth 2.0 / OpenID Connect authorization server, operated by DTI at
    oauth.simaster.ugm.ac.id. Issuer, endpoints, grants, scopes and claims are published in both an
    OIDC Discovery document and an RFC 8414 authorization server metadata document. The OpenAPI
    that describes it is written by UGM in Indonesian and is the institution's own contract.
  issuer: oauth.simaster.ugm.ac.id
  discovery:
  - https://oauth.simaster.ugm.ac.id/.well-known/openid-configuration
  - https://oauth.simaster.ugm.ac.id/.well-known/oauth-authorization-server
  endpoints:
    authorization: https://oauth.simaster.ugm.ac.id/oauth/authorize
    token: https://oauth.simaster.ugm.ac.id/oauth/token
    introspection: https://oauth.simaster.ugm.ac.id/oauth/introspect
    revocation: https://oauth.simaster.ugm.ac.id/oauth/revoke
    userinfo: https://oauth.simaster.ugm.ac.id/userinfo
    end_session: https://oauth.simaster.ugm.ac.id/oauth/logout
    jwks: https://oauth.simaster.ugm.ac.id/.well-known/jwks.json
  grant_types:
  - authorization_code
  - password
  - client_credentials
  - refresh_token
  - urn:ietf:params:oauth:grant-type:google_id_token
  - urn:ietf:params:oauth:grant-type:token-exchange
  pkce:
    supported: true
    code_challenge_methods: [S256]
  client_auth_methods: [client_secret_basic, client_secret_post, none]
  id_token_signing_alg: [RS256]
  response_types: [code]
  claims:
  - sub
  - iss
  - aud
  - exp
  - iat
  - auth_time
  - name
  - given_name
  - family_name
  - picture
  - email
  - email_verified
  - preferred_username
  - unit_id
  social_login:
  - google
  - microsoft
  - facebook
  - linkedin
  - apple
  rfcs_implemented:
  - RFC 6749 (OAuth 2.0)
  - RFC 7009 (Token Revocation)
  - RFC 7636 (PKCE)
  - RFC 7662 (Token Introspection)
  - RFC 8414 (Authorization Server Metadata)
  - RFC 8693 (Token Exchange)
  - OpenID Connect Core + Discovery
  defects_observed:
  - defect: >-
      Both discovery documents emit scheme-less URLs. `issuer` is "oauth.simaster.ugm.ac.id" and
      every endpoint is "oauth.simaster.ugm.ac.id/oauth/..." rather than an absolute https:// URL.
      OIDC Discovery and RFC 8414 both require absolute URLs; a conforming client library will
      reject or mis-resolve these. Recorded as observed, not corrected.
    probed: '2026-09-01'
    location: https://oauth.simaster.ugm.ac.id/.well-known/openid-configuration
    status: 200
  - defect: >-
      https://oauth.simaster.ugm.ac.id/.well-known/jwks.json returns HTTP 200 with an EMPTY key set,
      {"keys":[]}. RS256 id_tokens are advertised but no public key is published, so no relying
      party can verify a token offline. The endpoint is documented in the OpenAPI as getJwks.
    probed: '2026-09-01'
    location: https://oauth.simaster.ugm.ac.id/.well-known/jwks.json
    status: 200
  - defect: >-
      The `password` (resource owner credentials) grant and `none` client authentication are both
      advertised. The OpenAPI's own description flags `none` as legacy and slated for removal.
    probed: '2026-09-01'
    location: https://oauth.simaster.ugm.ac.id/openapi.json
    status: 200
  onboarding:
    self_service: false
    note: >-
      No client registration page, no dynamic client registration endpoint, and no published
      request process were found. Client credentials appear to be issued internally by DTI to UGM
      units. An outside developer has read access to the contract and to /health, and nothing else.

- name: ugm-shibboleth-saml2
  type: saml2
  x-operator: institution
  description: >-
    UGM's own Shibboleth Identity Provider at sso.ugm.ac.id, publishing an unsigned SAML 2.0
    EntityDescriptor from its own host. Advertises SAML 2.0, SAML 1.1 and the native Shibboleth
    authn profile, with an AttributeAuthorityDescriptor alongside the IDPSSODescriptor. This is
    institutional SSO infrastructure, not a developer API: an application cannot obtain an
    assertion without being registered as a service provider.
  entity_id: https://sso.ugm.ac.id/idp/shibboleth
  metadata:
  - https://sso.ugm.ac.id/idp/shibboleth
  - https://sso.ugm.ac.id/idp/profile/Metadata/SAML
  local_copy: authentication/gadjah-mada-university-saml-idp-metadata.xml
  scope: ac.id
  protocols:
  - urn:mace:shibboleth:1.0
  - urn:oasis:names:tc:SAML:1.1:protocol
  - urn:oasis:names:tc:SAML:2.0:protocol
  endpoints:
  - binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
    location: https://sso.ugm.ac.id/idp/profile/SAML2/Redirect/SSO
  - binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
    location: https://sso.ugm.ac.id/idp/profile/SAML2/POST/SSO
  - binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
    location: https://sso.ugm.ac.id/idp/profile/SAML2/POST-SimpleSign/SSO
  - binding: urn:mace:shibboleth:1.0:profiles:AuthnRequest
    location: https://sso.ugm.ac.id/idp/profile/Shibboleth/SSO
  - binding: urn:oasis:names:tc:SAML:2.0:bindings:SOAP
    location: https://sso.ugm.ac.id/idp/profile/SAML2/SOAP/AttributeQuery
    role: AttributeAuthority
  name_id_formats:
  - urn:mace:shibboleth:1.0:nameIdentifier
  - urn:oasis:names:tc:SAML:2.0:nameid-format:transient
  single_logout:
  - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
  - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
  - urn:oasis:names:tc:SAML:2.0:bindings:SOAP
  defects_observed:
  - defect: >-
      shibmd:Scope is declared as "ac.id" — the whole Indonesian academic second-level domain —
      rather than "ugm.ac.id". A scope that broad asserts authority over every Indonesian
      institution's namespace and would be rejected by a federation operator on registration.
    probed: '2026-09-01'
    location: https://sso.ugm.ac.id/idp/shibboleth
    status: 200
  - defect: >-
      The signing certificate in the descriptor was issued 2014-12-16 (valid to 2034-12-16), an
      11-year-old key still in production use.
    probed: '2026-09-01'
    location: authentication/gadjah-mada-university-saml-idp-metadata.xml
    status: local
  - defect: >-
      The entity is NOT present in the eduGAIN metadata aggregate. The full eduGAIN entity list
      (10,616 entities, retrieved 2026-09-01) contains no ugm.ac.id entity, so the IdP is
      self-published only and not inter-federated.
    probed: '2026-09-01'
    location: https://technical.edugain.org/api.php?action=list_entities&format=json
    status: 200

- name: ugm-cas
  type: cas
  x-operator: institution
  description: >-
    Central Authentication Service at sso.ugm.ac.id/cas, the login surface UGM systems redirect to.
    A bare GET redirects to /cas/login and returns the login form. CAS is a ticket protocol with a
    machine-readable /serviceValidate response, but UGM publishes no service registration route and
    no protocol documentation, so it is recorded as an authentication surface rather than an API.
  endpoints:
    login: https://sso.ugm.ac.id/cas/login
  probed: '2026-09-01'
  status: 200