Temple Health Authentication

generated: '2026-08-15'
method: probed
source: Live GET of the SMART configuration, the OIDC discovery document and the JWKS on epicaccess.templehealth.org
  (all HTTP 200, 2026-08-15), plus an observed 401 challenge on GET /FHIR/R4/Patient/example. Reconciled
  against the oauth2 securityScheme in openapi/*.yml.
summary:
  types:
  - oauth2
  - openIdConnect
  oauth2_flows:
  - authorizationCode
  - clientCredentials
  - refreshToken
  - jwtBearer
  - tokenExchange
  pkce: S256 (only method supported)
  client_auth:
  - client_secret_post
  - client_secret_basic
  - private_key_jwt
  bearer_challenge: 'WWW-Authenticate: Bearer (observed on 401; no realm, no resource_metadata)'
  anonymous_endpoints:
  - /FHIR/R4/metadata
  - /FHIR/R4/.well-known/smart-configuration
  - /FHIR/DSTU2/metadata
  - /FhirProxyPrd/oauth2/.well-known/openid-configuration
schemes:
- name: smartOnFhir
  type: oauth2
  flows:
  - flow: authorizationCode
    authorizationUrl: https://epicaccess.templehealth.org/FhirProxyPrd/oauth2/authorize
    tokenUrl: https://epicaccess.templehealth.org/FhirProxyPrd/oauth2/token
    scopes: 13
  description: SMART on FHIR / OAuth 2.0 with PKCE for patient-facing and provider-facing app launches.
  sources:
  - openapi/temple-health-allergy-intolerance-api-openapi.yml
  - openapi/temple-health-bulk-data-api-openapi.yml
  - openapi/temple-health-condition-api-openapi.yml
  - openapi/temple-health-document-reference-api-openapi.yml
  - openapi/temple-health-encounter-api-openapi.yml
  - openapi/temple-health-medication-request-api-openapi.yml
  - openapi/temple-health-metadata-api-openapi.yml
  - openapi/temple-health-observation-api-openapi.yml
  - openapi/temple-health-patient-api-openapi.yml
docs: https://fhir.epic.com/Documentation
docs_note: There is no Temple Health-authored authentication page. Epic on FHIR documents the SMART/OAuth
  model generally; the Temple-specific facts come only from the endpoint.
discovery:
  smart_configuration:
    url: https://epicaccess.templehealth.org/FhirProxyPrd/api/FHIR/R4/.well-known/smart-configuration
    status: 200
    file: well-known/temple-health-smart-configuration.json
  openid_configuration:
    url: https://epicaccess.templehealth.org/FhirProxyPrd/oauth2/.well-known/openid-configuration
    status: 200
    file: well-known/temple-health-openid-configuration.json
  jwks:
    url: https://epicaccess.templehealth.org/FhirProxyPrd/api/epic/2019/Security/Open/PublicKeys/530027/OIDC
    status: 200
    file: well-known/temple-health-oidc-jwks.json
  oauth_authorization_server_rfc8414:
    status: 404
  oauth_protected_resource_rfc9728:
    status: 404
  dstu2_smart_configuration:
    status: 404
    note: The legacy DSTU2 base publishes no SMART discovery document; read the oauth-uris extension from
      its Conformance resource instead.
openid_connect:
  issuer: https://epicaccess.templehealth.org/FhirProxyPrd/oauth2
  id_token_signing_alg_values_supported:
  - RS256
  subject_types_supported:
  - public
  response_types_supported:
  - code
  response_modes_supported:
  - query
profiles:
- name: SMART App Launch — standalone patient
  grant: authorization_code + PKCE S256
  client: public or confidential
  use: Patient-access apps under CMS-9115-F
  capability_evidence:
  - launch-standalone
  - context-standalone-patient
  - permission-patient
  - permission-offline
- name: SMART App Launch — EHR launch
  grant: authorization_code + PKCE S256
  client: confidential
  use: Provider-facing apps launched from inside Epic
  capability_evidence:
  - launch-ehr
  - context-ehr-patient
  - context-ehr-encounter
  - permission-user
- name: SMART Backend Services
  grant: client_credentials with private_key_jwt (RFC 7523)
  client: confidential-asymmetric
  use: Bulk Data Group $export under a data-use agreement
  capability_evidence:
  - client-confidential-asymmetric
onboarding:
  app_registration: https://fhir.epic.com/Developer/Apps
  production_access: Approved by Temple Health per app against the production endpoint; no self-service
    path.
  endpoint_directory: https://open.epic.com/Endpoints/R4
gaps:
- No RFC 9728 protected-resource metadata — the 401 challenge carries no pointer to the authorization
  server.
- No RFC 8414 authorization-server metadata at either the origin root or the FHIR base.
- The 401 body is an empty JSON string, not an OperationOutcome — no machine-readable reason for the rejection.
- No dynamic client registration endpoint published.