Cardiosense Authentication

generated: '2026-08-09'
method: probed
source: https://cardiosense.com/.well-known/oauth-authorization-server
description: >-
  Cardiosense publishes no developer API and no authentication documentation.
  The authentication profile below is not derived from an OpenAPI
  securitySchemes block — there is no OpenAPI — it is read directly from the
  two OAuth discovery documents the host serves anonymously, plus the
  authentication block of the public WordPress REST route index.
docs: null
docs_note: >-
  There is no published auth guide. Everything here came from machine-readable
  discovery documents, not from prose a developer could read.

schemes:
  - id: mcp_oauth2
    type: oauth2
    flow: authorization_code
    applies_to: https://cardiosense.com/wp-json/mcp/mcp-oauth-server
    issuer: https://cardiosense.com
    authorization_endpoint: https://cardiosense.com/oauth/authorize
    token_endpoint: https://cardiosense.com/oauth/token
    revocation_endpoint: https://cardiosense.com/oauth/revoke
    response_types_supported: [code]
    grant_types_supported: [authorization_code, refresh_token]
    code_challenge_methods_supported: [S256]
    token_endpoint_auth_methods_supported: [none]
    bearer_methods_supported: [header]
    scopes: [mcp]
    client_identification: >-
      client_id_metadata_document_supported = true. No RFC 7591 dynamic client
      registration endpoint is advertised, so a client is identified by a URL
      pointing at its own client-ID metadata document.
    observations:
      - PKCE is mandatory in practice — S256 is the only challenge method offered and no client secret method is supported.
      - Public-client only (`none`); there is no confidential-client path.
      - A refresh_token grant is offered, but no token lifetime or rotation policy is published.
      - No id_token / OpenID Connect layer — /.well-known/openid-configuration returns 404.
    evidence:
      url: https://cardiosense.com/.well-known/oauth-authorization-server
      http_status: 200

  - id: wp_application_passwords
    type: http
    scheme: basic
    applies_to: https://cardiosense.com/wp-json/
    description: >-
      The WordPress REST API index advertises Application Passwords as its
      authentication mechanism, authorized at
      https://cardiosense.com/wp-admin/authorize-application.php. This is a
      WordPress platform default rather than a Cardiosense product decision,
      and it gates the CMS content routes and the default MCP server.
    evidence:
      url: https://cardiosense.com/wp-json/
      http_status: 200

anonymous_access:
  - surface: https://cardiosense.com/llms.txt
    authenticated: false
    status: 200
  - surface: https://cardiosense.com/wp-json/ (route index)
    authenticated: false
    status: 200
  - surface: https://cardiosense.com/wp-json/mcp/mcp-oauth-server
    authenticated: true
    status: 401
  - surface: https://cardiosense.com/wp-json/wp-abilities/v1/abilities
    authenticated: true
    status: 401

gaps:
  - No human-readable authentication documentation exists for the MCP surface.
  - No dynamic client registration endpoint, so onboarding an agent client requires an out-of-band conversation with Cardiosense.
  - Token lifetimes, refresh rotation, and scope semantics for `mcp` are undocumented.

x-evidence:
  fetched: '2026-08-09'
  probes:
    - url: https://cardiosense.com/.well-known/oauth-authorization-server
      status: 200
    - url: https://cardiosense.com/.well-known/oauth-protected-resource
      status: 200
    - url: https://cardiosense.com/.well-known/openid-configuration
      status: 404
    - url: https://cardiosense.com/wp-json/
      status: 200