generated: '2026-08-29'
method: probed
source: https://auth.tailormed.com/.well-known/openid-configuration
docs: https://hub.tailormed.co/dta/api-documentation
name: TailorMed authentication profile
description: >-
  Authentication profile derived from the OpenID Connect discovery document and the
  OAuth 2.0 authorization server metadata that TailorMed serves at auth.tailormed.com,
  plus the OAuth client configuration shipped in the public TailorMed platform SPA
  bundle. TailorMed publishes no OpenAPI, so no securityScheme block could be read;
  everything below was observed on the wire.
note: >-
  auth.tailormed.com is an Okta org authorization server on a TailorMed-controlled
  custom domain (CNAME -> tailormed-platform.customdomains.okta-dnssec.com). Its issuer
  is "https://auth.tailormed.com". A second, tenant-scoped authorization server is
  reachable at /oauth2/default and reports issuer
  "https://tailormed-platform.okta.com/oauth2/default". The data-exchange APIs
  (Application Data API, Claims Data API, HL7/FHIR) are documented only behind the
  login on hub.tailormed.co, so their credential model could not be read publicly.
schemes:
- name: openIdConnect
  type: openIdConnect
  openIdConnectUrl: https://auth.tailormed.com/.well-known/openid-configuration
  issuer: https://auth.tailormed.com
  evidence: 'HTTP 200, application/json, fetched 2026-08-29'
- name: oauth2
  type: oauth2
  flows:
    authorizationCode:
      authorizationUrl: https://auth.tailormed.com/oauth2/v1/authorize
      tokenUrl: https://auth.tailormed.com/oauth2/v1/token
      refreshUrl: https://auth.tailormed.com/oauth2/v1/token
    deviceCode:
      deviceAuthorizationUrl: https://auth.tailormed.com/oauth2/v1/device/authorize
  evidence: >-
    https://auth.tailormed.com/.well-known/oauth-authorization-server, HTTP 200
endpoints:
  authorization: https://auth.tailormed.com/oauth2/v1/authorize
  token: https://auth.tailormed.com/oauth2/v1/token
  userinfo: https://auth.tailormed.com/oauth2/v1/userinfo
  jwks: https://auth.tailormed.com/oauth2/v1/keys
  introspection: https://auth.tailormed.com/oauth2/v1/introspect
  revocation: https://auth.tailormed.com/oauth2/v1/revoke
  end_session: https://auth.tailormed.com/oauth2/v1/logout
  device_authorization: https://auth.tailormed.com/oauth2/v1/device/authorize
  dynamic_client_registration: https://auth.tailormed.com/oauth2/v1/clients
grant_types:
- authorization_code
- implicit
- refresh_token
- password
- 'urn:ietf:params:oauth:grant-type:device_code'
response_types:
- code
- id_token
- code id_token
- code token
- id_token token
- code id_token token
token_endpoint_auth_methods:
- client_secret_basic
- client_secret_post
- client_secret_jwt
- private_key_jwt
- none
pkce:
  supported: true
  code_challenge_methods:
  - S256
id_token_signing_alg_values:
- RS256
subject_types:
- public
observations:
- >-
  PKCE is advertised with S256 only (no plain), and the public SPA client uses the
  authorization-code + PKCE flow with token_endpoint_auth_method "none".
- >-
  The resource-owner password grant is still advertised on the org authorization
  server. That is an Okta org-server default rather than a documented TailorMed
  integration path, but it is what the metadata says.
- >-
  Dynamic client registration is advertised at /oauth2/v1/clients; it was not
  exercised.
api_keys:
  documented: unknown
  note: >-
    The Implementation Hub's own backend rejects unauthenticated calls with
    {"error":"Missing or invalid Authorization header"} (HTTP 401 on
    https://hub.tailormed.co/api/v1/openapi.json and every other /api/* path probed),
    which shows a bearer-style Authorization header is expected, but the scheme is not
    described on any public page.