Micro Connect Authentication

generated: '2026-08-25'
method: probed
source: >-
  https://kc.mcisaas.com/auth/realms/numa-realm/.well-known/openid-configuration (HTTP 200)
  and https://kc.mcisaas.com/auth/realms/master/.well-known/openid-configuration (HTTP 200),
  saved verbatim in well-known/. Client identity read from Micro Connect's own published JS
  (https://mcisaas.com/mcc-share/domain.js and the Open Platform bundle at
  https://open.microconnect.cn/mcc-open/assets/index.4743a4fd.js).
docs: null
docs_note: >-
  Micro Connect publishes no authentication documentation. Everything here was read off the
  live, anonymous OpenID Connect discovery documents and the provider's own browser bundle;
  nothing is inferred.
summary: >-
  The Micro Connect SaaS estate authenticates against a self-hosted Keycloak identity
  provider at kc.mcisaas.com using OpenID Connect / OAuth 2.0. There is no API-key surface,
  no public client registration, and no published developer credential flow — an integrator
  must first be registered as an enterprise account on the Open Platform.
identity_provider:
  product: Keycloak (self-hosted)
  host: kc.mcisaas.com
  path_style: legacy /auth/ prefix
  realms:
  - name: numa-realm
    issuer: https://kc.mcisaas.com/auth/realms/numa-realm
    used_by: >-
      Micro Connect Open Platform SPA (open.microconnect.com / open.microconnect.cn),
      clientId web-mcc-open-platform
    discovery: https://kc.mcisaas.com/auth/realms/numa-realm/.well-known/openid-configuration
    status: 200
  - name: master
    issuer: https://kc.mcisaas.com/auth/realms/master
    used_by: Keycloak administration realm
    discovery: https://kc.mcisaas.com/auth/realms/master/.well-known/openid-configuration
    status: 200
schemes:
- name: openIdConnect
  type: openIdConnect
  openIdConnectUrl: https://kc.mcisaas.com/auth/realms/numa-realm/.well-known/openid-configuration
  in: header
  parameter: Authorization
  format: Bearer <access_token>
  note: >-
    The Open Platform SPA obtains a Keycloak access token and presents it as a bearer token
    to the ShenYu gateway at https://api.mcisaas.com/api.
- name: oauth2
  type: oauth2
  flows:
  - authorization_code
  - implicit
  - refresh_token
  - password
  - client_credentials
  - urn:ietf:params:oauth:grant-type:device_code
  - urn:openid:params:grant-type:ciba
  authorization_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/auth
  token_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/token
  introspection_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/token/introspect
  userinfo_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/userinfo
  revocation_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/revoke
  end_session_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/logout
  jwks_uri: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/certs
  registration_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/clients-registrations/openid-connect
  pushed_authorization_request_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/ext/par/request
  device_authorization_endpoint: https://kc.mcisaas.com/auth/realms/numa-realm/protocol/openid-connect/auth/device
capabilities:
  pkce: true
  pkce_methods:
  - plain
  - S256
  par_supported: true
  par_required: false
  mtls_bound_access_tokens: true
  token_endpoint_auth_methods:
  - private_key_jwt
  - client_secret_basic
  - client_secret_post
  - tls_client_auth
  - client_secret_jwt
  backchannel_logout: true
  frontchannel_logout: true
  dynamic_client_registration_endpoint_present: true
  request_object_supported: true
observations:
- >-
  Strong protocol capability, zero developer-facing exposure: the identity provider supports
  PKCE (S256), Pushed Authorization Requests, mTLS-bound access tokens, private_key_jwt and
  CIBA — a FAPI-grade toolkit — but none of it is documented anywhere a prospective
  integrator can read, and no client can be obtained without an enrolled enterprise account.
- >-
  The `implicit` and `password` grants are still advertised as supported on both realms.
  Both are discouraged by OAuth 2.0 Security Best Current Practice (RFC 9700) and removed in
  OAuth 2.1; this is a Keycloak default rather than an explicit Micro Connect decision, but
  it is what the discovery document advertises today.