generated: '2026-08-13'
method: searched
source: https://open.fxiaoke.com/.well-known/oauth-authorization-server
docs:
- https://developer.fxiaoke.com/openapi_v2/start/auth/auth-code.html
- https://developer.fxiaoke.com/openapi_v2/start/guide/codes.html
- https://www.fxiaoke.com/secure/index.html

standards:
- id: oauth2
  conforms: partial
  evidence: >-
    Two authorization-code/client-credentials surfaces exist. The RFC 8414 metadata at
    https://open.fxiaoke.com/.well-known/oauth-authorization-server describes a
    conformant server (authorization_code + refresh_token, PKCE S256, public clients).
    The flow the developer manual actually documents uses non-RFC parameter names —
    appId instead of client_id, redirectUrl instead of redirect_uri, responseType
    instead of response_type, grantType instead of grant_type — so a standards-compliant
    OAuth client library cannot drive the documented flow without custom mapping.

- id: rfc8414-oauth-authorization-server-metadata
  conforms: true
  evidence: >-
    /.well-known/oauth-authorization-server returns HTTP 200 with a valid JSON metadata
    document (re-verified 2026-08-13). Issuer https://open.fxiaoke.com/oauth2.0.

- id: rfc7636-pkce
  conforms: true
  evidence: code_challenge_methods_supported = [S256] in the RFC 8414 metadata.
  caveat: >-
    PKCE applies only to the undocumented /oauth2.0/pkce/token surface. The
    authorization-code flow in the developer manual does not use PKCE.

- id: rfc7591-dynamic-client-registration
  conforms: true
  evidence: registration_endpoint = https://open.fxiaoke.com/oauth2.0/register

- id: rfc9728-oauth-protected-resource-metadata
  conforms: false
  evidence: >-
    /.well-known/oauth-protected-resource returns HTTP 200 but the body is the API
    gateway's errorCode 10006 "uri is not exists" envelope, not protected-resource
    metadata. No resource server is advertised for the tokens the AS issues.

- id: oidc-discovery
  conforms: partial
  evidence: >-
    /oauth2.0/.well-known/openid-configuration is served and id_token_signing_alg =
    RS256, but jwks_uri (https://open.fxiaoke.com/oauth2.0/jwks) returns {"keys":[]}
    — re-verified 2026-08-13 — and no userinfo endpoint or scopes_supported is
    advertised. Treated as an OAuth 2.1 authorization server with OIDC-shaped discovery
    rather than a full OIDC provider. An empty JWKS means no client following discovery
    can verify an issued id_token.

- id: rfc9457-problem-details
  conforms: false
  evidence: >-
    Responses use a custom errorCode / errorMessage / errorDescription / traceId
    envelope, not application/problem+json.

- id: http-status-semantics
  conforms: false
  evidence: >-
    The gateway returns HTTP 200 for business errors, authorization failures, quota
    exhaustion and unrecognised paths alike, encoding the outcome in a body errorCode.
    An unknown POST path returns 200 with errorCode 10006 rather than 404. Clients
    cannot rely on the status line for any application decision.

- id: rfc9116-security-txt
  conforms: false
  evidence: no /.well-known/security.txt on the API, developer or corporate hosts

- id: rfc4122-uuid
  conforms: true
  evidence: >-
    Every endpoint requires a caller-supplied thirdTraceId, and the docs mandate RFC
    4122 UUID version 4 format, with a worked example.
  source: https://developer.fxiaoke.com/openapi_v2/start/example/public.html

- id: idempotency
  conforms: false
  evidence: >-
    No idempotency key or request-deduplication window is documented for write
    operations. thirdTraceId must be unique per request, so it cannot serve as one.

- id: pagination
  conforms: partial
  evidence: >-
    Offset pagination via search_query_info {limit, offset} with a documented hard cap
    of offset 10000 (errorCode 10013) and a published keyset workaround ordering by _id
    with an _id GT filter. Documented, but non-standard and with no cursor token.

- id: openapi
  conforms: false
  evidence: >-
    No OpenAPI, Swagger, GraphQL SDL, AsyncAPI or Protobuf definition is published. All
    1,080+ operation reference pages are hand-written HTML. Probes of
    /openapi.json, /openapi.yaml, /swagger.json, /v1/openapi.json, /api-docs,
    /v2/api-docs, /docs, /redoc and /asyncapi.yaml against open.fxiaoke.com,
    developer.fxiaoke.com and www.fxiaoke.com all missed (2026-08-13).

compliance_certifications:
  published: true
  source: https://www.fxiaoke.com/secure/index.html
  certifications:
  - ISO/IEC 27001 (GB/T22080-2016)
  - ISO/IEC 27701
  - ISO/IEC 20000-1
  - ISO 9001:2015 (GB/T19001-2016)
  - 信息系统安全等级保护备案证明（三级） — China MLPS Level 3
  - SOC 1 (Type II)
  - SOC 2 (Type II)
  caveat: >-
    Named in prose inside the privacy policy with no certificate numbers, issuing bodies
    or validity dates, and no report-request process. Verifiable as a claim, not as a
    document.
  ref: security/fxiaoke-trust-center.yml

notes: >-
  Standards conformance is asserted from live RFC 8414 metadata, live probes re-run
  2026-08-13, and the developer documentation. The picture is bimodal: the
  authorization-server layer is genuinely standards-based, while the API layer itself is
  a proprietary JSON-RPC-over-POST design that opts out of HTTP semantics, problem
  details and machine-readable description entirely. A Compliance pointer IS emitted,
  because the provider publishes named third-party certifications.