Knight Frank · Authentication Profile

Knight Frank Authentication

Authentication

Knight Frank runs two authentication postures at once and neither is a developer credential. The corporate search service (api-v3) enforces NO authentication at all — its OpenAPI declares no securitySchemes, sends no security requirement, and answers anonymous GETs with real office and people-directory records. The property/account service (api-v2) is fully closed — every request without a bearer token returns 401 — and is protected by Azure AD B2C through a first-party MSAL client belonging to the consumer "My Knight Frank" saved-property account. There is no API key programme, no client-credentials flow, no developer application registration and no way for a third party to obtain a credential of any kind.

Knight Frank secures its APIs with none, oauth2, and openIdConnect across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode flow(s).

Real EstateUnited KingdomProperty ListingsCommercial Real EstateValuationBrokerageProperty ManagementRentalsPropTechResearch
Methods: none, oauth2, openIdConnect Schemes: 2 OAuth flows: authorizationCode API key in:

Security Schemes

none none
azure-ad-b2c openIdConnect
scheme: bearer · flows: authorizationCode

Source

Authentication Profile

Raw ↑
generated: '2026-07-26'
method: searched
source: >-
  Live probes of both Knight Frank service hosts on 2026-07-26, the harvested
  OpenAPI 3.0.1 document at openapi/knight-frank-api-v3-openapi.json, the two
  harvested Azure AD B2C OpenID Connect discovery documents in this directory,
  and the public client-side `kfsearchconfig` object plus the MSAL
  protected-resource map in the site's Angular bundle.
description: >-
  Knight Frank runs two authentication postures at once and neither is a
  developer credential. The corporate search service (api-v3) enforces NO
  authentication at all — its OpenAPI declares no securitySchemes, sends no
  security requirement, and answers anonymous GETs with real office and
  people-directory records. The property/account service (api-v2) is fully
  closed — every request without a bearer token returns 401 — and is protected
  by Azure AD B2C through a first-party MSAL client belonging to the consumer
  "My Knight Frank" saved-property account. There is no API key programme, no
  client-credentials flow, no developer application registration and no way for
  a third party to obtain a credential of any kind.
summary:
  types: [none, oauth2, openIdConnect]
  api_key_in: []
  oauth2_flows: [authorizationCode]
  developer_credential_available: false
schemes:
  - name: none
    type: none
    surface: https://api-v3.web.prd-knightfrank.com
    sources: [openapi/knight-frank-api-v3-openapi.json]
    detail: >-
      The harvested OpenAPI 3.0.1 document contains no components.securitySchemes
      block and no security array. Verified live on 2026-07-26: GET /office,
      GET /office/{id}, GET /person, GET /person/autocomplete, GET /person/cms-search,
      GET /search, GET /cmspage, GET /intelligencelab and GET /service-lines all
      returned HTTP 200 with real JSON to a client presenting no credential.
    evidence:
      - request: GET https://api-v3.web.prd-knightfrank.com/office?term=london&isoCode=GB&languageCode=en&maxResultCount=1
        status: 200
        result: one real office record (officeId 1976, 55 Baker Street, W1U 8AN) with no credential presented
      - request: GET https://api-v3.web.prd-knightfrank.com/person?term=smith&isoCode=GB&languageCode=en&maxResultCount=1
        status: 200
        result: one real staff record (empNo, direct dial, mobile, email) with no credential presented
  - name: azure-ad-b2c
    type: openIdConnect
    surface: https://api-v2.web.prd-knightfrank.com
    scheme: bearer
    bearerFormat: JWT
    sources:
      - authentication/knight-frank-b2c-mykfsignin-openid-configuration.json
      - authentication/knight-frank-b2clogin-mykfsignin-openid-configuration.json
    openIdConnectUrl: https://login.prd-knightfrank.com/ea15e386-0dbc-4a5b-ac74-08f50f444486/B2C_1A_MYKFSIGNIN/v2.0/.well-known/openid-configuration
    detail: >-
      Consumer identity, not developer identity. The Angular front end binds the
      api-v2 /secure base to an Azure AD B2C scope through an MSAL
      protectedResourceMap and drives an authorization-code redirect flow. Every
      anonymous request to /properties/search and /secure/account returns HTTP 401
      with a zero-byte body.
    provider:
      platform: Azure AD B2C
      tenant_domain: KnightFrankB2Cprod.onmicrosoft.com
      tenant_id: ea15e386-0dbc-4a5b-ac74-08f50f444486
      custom_domain: login.prd-knightfrank.com
      b2clogin_domain: knightfrankb2cprod.b2clogin.com
      policy: B2C_1A_MYKFSIGNIN
    flows:
      - flow: authorizationCode
        response_types: [code, code id_token, code token, code id_token token, id_token, id_token token, token, token id_token]
        token_endpoint_auth_methods: [client_secret_post, client_secret_basic]
        id_token_signing_alg: [RS256]
        subject_types: [pairwise]
    scopes_detail: scopes/knight-frank-scopes.yml
    claims_supported: [extension_HubContactId, oid, sub, tid, iss, iat, exp, aud, acr, nonce, auth_time]
    note: >-
      The custom claim extension_HubContactId links a B2C consumer account to a
      contact record in an internal Knight Frank "Hub" CRM.
developer_onboarding:
  self_serve_signup: false
  application_registration: false
  api_keys: false
  sandbox: false
  terms_for_api_use: false
  note: >-
    There is nothing to sign up for. No developer portal, no key issuance, no
    application registration and no API terms of use exist. The only account
    signup Knight Frank publishes (https://account.knightfrank.com/) is the
    consumer "My Knight Frank" saved-property account, which grants a B2C token
    scoped to that consumer's own saved properties and alerts — not API access.
docs: null
docs_note: Knight Frank publishes no authentication documentation of any kind.