Ipstack Authentication

generated: '2026-09-04'
method: probed
source: >-
  https://ipstack.com/how-to-use-ipstack-api/ (HTTP 200), https://ipstack.com/llms.txt
  (HTTP 200), live unauthenticated requests to https://api.ipstack.com/ (HTTP 200 error
  envelopes), and the RFC 9728 / RFC 8414 discovery documents served at
  mcp.apilayer.com and auth.apilayer.com (both HTTP 200). No OpenAPI is published, so this
  profile was probed and read from docs rather than derived from securitySchemes.
name: IPstack authentication profile
description: >-
  Two entirely different authentication models sit behind one product. The REST API uses a
  single static access key passed as a URL QUERY PARAMETER — the weakest of the common
  API key placements, since the credential lands in proxy logs, browser history and
  Referer headers. The MCP server in front of the same data uses a real OAuth 2.0
  deployment with discovery, PKCE and dynamic client registration.
schemes:
  - id: access_key
    api: ipstack REST API
    type: apiKey
    in: query
    name: access_key
    required: true
    description: >-
      Every request appends ?access_key=YOUR_ACCESS_KEY. There is no header alternative
      documented and none was accepted on probe. The key is issued from the dashboard at
      signup and is not rotated automatically.
    evidence:
      url: 'https://api.ipstack.com/134.201.250.155'
      http_status: 200
      body: >-
        {"success":false,"error":{"code":101,"type":"missing_access_key","info":"You have
        not supplied an API Access Key. [Required format: access_key=YOUR_ACCESS_KEY]"}}
    concerns:
      - >-
        Credential in the query string. It is written into access logs and CDN logs by
        default and is exposed in the Referer header of any resource the response loads.
      - >-
        Free tier is documented as HTTP-only in the historical plan matrix; all probes in
        this pass were served over HTTPS with a valid certificate.
  - id: apilayer_oauth
    api: ipstack MCP Server
    type: oauth2
    description: >-
      The MCP endpoint challenges anonymous callers with a conformant RFC 9728 header and
      publishes full protected-resource and authorization-server metadata.
    challenge: >-
      WWW-Authenticate: Bearer resource_metadata="https://mcp.apilayer.com/.well-known/oauth-protected-resource"
    issuer: https://auth.apilayer.com
    authorization_endpoint: https://auth.apilayer.com/oauth2/auth
    token_endpoint: https://auth.apilayer.com/oauth2/token
    registration_endpoint: https://auth.apilayer.com/oauth2/register
    revocation_endpoint: https://auth.apilayer.com/oauth2/revoke
    device_authorization_endpoint: https://auth.apilayer.com/oauth2/device/auth
    jwks_uri: https://auth.apilayer.com/.well-known/jwks.json
    grant_types:
      - authorization_code
      - implicit
      - client_credentials
      - refresh_token
      - 'urn:ietf:params:oauth:grant-type:device_code'
    code_challenge_methods:
      - S256
    token_endpoint_auth_methods:
      - client_secret_post
      - client_secret_basic
      - private_key_jwt
      - none
    scopes:
      - openid
      - offline
      - offline_access
      - mcp:read
      - api:ipstack
    evidence:
      url: https://mcp.apilayer.com/mcp
      http_status: 401
      body: '{"jsonrpc":"2.0","error":{"code":-32001,"message":"Authentication required"},"id":null}'
    note: >-
      The provider's own published client config uses a static bearer token
      (APILAYER_MCP_TOKEN) rather than the OAuth flow, so both paths appear to be accepted.
transport_security:
  tls: true
  note: >-
    All probed hosts served valid TLS. api.ipstack.com rejects HEAD with HTTP 403 and
    answers GET on HTTP/1.0; CORS is wide open (access-control-allow-origin: *).
docs:
  - https://ipstack.com/how-to-use-ipstack-api/
  - https://docs.apilayer.com/ipstack/docs/api-documentation