Crea Authentication

generated: '2026-07-26'
method: searched
source: https://ddfapi-docs.realtor.ca/ (Authorization section), https://boardapi-docs.realtor.ca/ (Authorization section)
docs: https://ddfapi-docs.realtor.ca/#section/Authorization
discovery: https://identity.crea.ca/.well-known/openid-configuration
description: >-
  Every REALTOR.ca API is fronted by a single Duende/IdentityServer deployment at
  identity.crea.ca. Neither OpenAPI document declares a securityScheme - the derived pass over
  openapi/ found zero schemes across all three specs - so this profile is taken from the
  provider's own Authorization documentation and from the anonymous OpenID Connect discovery
  document, both harvested 2026-07-26. The only supported machine flow is OAuth 2.0 client
  credentials; credentials are issued by CREA and there is no self-serve path.
summary:
  types: [oauth2, openIdConnect]
  api_key_in: []
  oauth2_flows: [clientCredentials]
  spec_declared_schemes: 0
  self_serve_signup: false
schemes:
- name: CREA IdentityServer client credentials
  type: oauth2
  flow: clientCredentials
  token_url: https://identity.crea.ca/connect/token
  request_encoding: application/x-www-form-urlencoded
  client_authentication: [client_secret_basic, client_secret_post]
  parameters:
    client_id: The username of your Destination (DDF data feed) or Board
    client_secret: The password of your Destination or Board
    grant_type: client_credentials
    scope: DDFApi_Read (DDF Web API and Lead API) or BoardDataApi.read (Board API)
  response_fields:
    access_token: The bearer token
    expires_in: 3600 by default; the token is NOT sliding, a new token must be requested after one hour
    token_type: Bearer
    scope: Echoes the requested scope
  token_placement: Authorization header, "Bearer <access_token>"
  applies_to:
  - crea:realtor-ca-ddf-web-api
  - crea:realtor-ca-ddf-lead-api
  - crea:realtor-ca-board-api
  sources: [https://ddfapi-docs.realtor.ca/, https://boardapi-docs.realtor.ca/]
- name: CREA OpenID Connect provider
  type: openIdConnect
  issuer: https://identity.crea.ca
  openid_configuration: https://identity.crea.ca/.well-known/openid-configuration
  jwks_uri: https://identity.crea.ca/.well-known/openid-configuration/jwks
  authorization_endpoint: https://identity.crea.ca/connect/authorize
  token_endpoint: https://identity.crea.ca/connect/token
  userinfo_endpoint: https://identity.crea.ca/connect/userinfo
  introspection_endpoint: https://identity.crea.ca/connect/introspect
  revocation_endpoint: https://identity.crea.ca/connect/revocation
  end_session_endpoint: https://identity.crea.ca/connect/endsession
  device_authorization_endpoint: https://identity.crea.ca/connect/deviceauthorization
  pushed_authorization_request_endpoint: https://identity.crea.ca/connect/par
  require_pushed_authorization_requests: false
  grant_types_supported: [authorization_code, client_credentials, refresh_token, implicit, 'urn:ietf:params:oauth:grant-type:device_code', 'urn:openid:params:grant-type:ciba']
  code_challenge_methods_supported: [plain, S256]
  id_token_signing_alg_values_supported: [RS256]
  token_endpoint_auth_methods_supported: [client_secret_basic, client_secret_post]
  claims_supported: [sub, destinationid]
  subject_types_supported: [public]
  frontchannel_logout_supported: true
  backchannel_logout_supported: true
  note: >-
    The discovery document advertises far more than the documented APIs use. Only
    client_credentials is documented for DDF and Board; authorization_code, implicit, device
    code and CIBA are advertised by the shared identity server and are presumably used by
    CREA's member-facing products (DDF Dashboard, WEBForms, Offer Management). The
    "destinationid" claim is what scopes a DDF token to a data feed.
credential_issuance:
  self_serve: false
  process: >-
    A REALTOR opts a data feed in through the DDF Dashboard on CREA's member portal
    (ddf.realtor.ca, SSO via sso.realtor.ca). A third-party developer must enter a data access
    agreement with CREA as a Technology Provider operating a National Pool Website or Member
    Website on behalf of that opted-in member. client_id and client_secret are then provided
    by CREA. Board API credentials are provided by CREA to member boards.
  gotchas:
  - An inactive data feed returns no access token at all, rather than an error explaining why.
  - Technology Provider accounts get their own credentials that merge every linked feed into one unified dataset.
  - CREA recommends server-to-server token use only; client-to-server token requests are called out as a security risk.
transport_security:
  min_tls: '1.2'
  https_required: true
  source: Release note 2023-01-31 - "Update to support minimum TLS version 1.2 enforcing all incoming requests to be HTTPS."
related:
  scopes: scopes/crea-scopes.yml
  well_known: well-known/crea-well-known.yml
  conventions: conventions/crea-conventions.yml