Independence Blue Cross Authentication

generated: '2026-08-15'
method: probed
source: >-
  https://eapics.ibx.com/patient/v1/fhir/.well-known/smart-configuration (HTTP 200, live probe 2026-08-15),
  https://eapics.ibx.com/provider/v1/fhir/.well-known/smart-configuration (HTTP 200),
  https://eapics.ibx.com/formulary/v1/fhir/.well-known/smart-configuration (HTTP 200),
  https://www.ibx.com/scripts/custom/swagger/cmsSwagger.json (provider-published Swagger 2.0),
  openapi/_original/independence-blue-cross-patient-openapi.yml,
  https://www.ibx.com/htdocs/custom/tnc/Developer%20Portal%20TandC.pdf
docs: https://www.ibx.com/developer-resources/index.html
previous_method: derived
upgrade_note: >-
  Upgraded from derived to probed. The 2026-07-11 pass read the auth model out of the OpenAPI alone;
  this pass fetched the live SMART App Launch configuration from all three FHIR base paths and
  reconciled it against the provider's own published Swagger description. The endpoints agree, and the
  live documents add the capability set, which the spec does not carry.
summary:
  types:
    - oauth2
  oauth2_flows:
    - authorizationCode
  profile: SMART App Launch 1.0.0
  split_surface: true
  split_note: >-
    Only one of the three Independence Blue Cross APIs is authenticated. Patient Access requires SMART
    on FHIR OAuth 2.0 with member consent; the Provider Directory and Drug Formulary require nothing at
    all. The provider states this plainly in its Swagger info.description: those two APIs "do not
    require authorization to access the data on the server, because customer data is not being shared."
schemes:
  - name: smart_on_fhir
    type: oauth2
    profile: SMART App Launch 1.0.0
    applies_to: Independence Blue Cross Patient Access API
    base: https://eapics.ibx.com/patient/v1/fhir
    token_placement: 'Authorization: Bearer {access_token}'
    flows:
      - flow: authorizationCode
        authorizationUrl: https://member.ibx.com/patientaccesssvc/oauth2/v1/authorize
        tokenUrl: https://eapics.ibx.com/oauth2/v2/token
        pkce: required-for-public-clients
        scopes: 4
        scope_list:
          - launch/patient
          - patient/*.read
          - openid
          - offline_access
    sources:
      - openapi/_original/independence-blue-cross-patient-openapi.yml
      - https://eapics.ibx.com/patient/v1/fhir/.well-known/smart-configuration
    cross_link: scopes/independence-blue-cross-scopes.yml
  - name: public
    type: none
    applies_to:
      - Independence Blue Cross Provider Directory API
      - Independence Blue Cross Drug Formulary API
    bases:
      - https://eapics.ibx.com/provider/v1/fhir
      - https://eapics.ibx.com/formulary/v1/fhir
    evidence: >-
      Provider Swagger info.description; confirmed by openapi/_original/independence-blue-cross-provider-openapi.yml
      and openapi/_original/independence-blue-cross-formulary-openapi.yml declaring no securitySchemes.
smart_configuration:
  discovery_pattern: '{base}/.well-known/smart-configuration'
  probed: '2026-08-15'
  documents:
    - base: https://eapics.ibx.com/patient/v1/fhir
      status: 200
      authorization_endpoint: https://member.ibx.com/patientaccesssvc/oauth2/v1/authorize
      token_endpoint: https://eapics.ibx.com/oauth2/v2/token
      file: well-known/independence-blue-cross-patient-smart-configuration.json
    - base: https://eapics.ibx.com/provider/v1/fhir
      status: 200
      authorization_endpoint: https://member.ibx.com/patientaccesssvc/oauth2/v1/authorize
      token_endpoint: https://eapics.ibx.com/oauth2/v2/token
      file: well-known/independence-blue-cross-provider-smart-configuration.json
    - base: https://eapics.ibx.com/formulary/v1/fhir
      status: 200
      authorization_endpoint: https://member.amerihealth.com/patientaccesssvc/oauth2/v1/authorize
      token_endpoint: https://eapics.amerihealth.com/oauth2/v1/token
      file: well-known/independence-blue-cross-formulary-smart-configuration.json
      deviation: >-
        Cross-brand. This document is served from an ibx.com host but names AmeriHealth authorization
        and token endpoints. AmeriHealth is a sibling payer under the same parent, Independence Health
        Group, Inc., and the two evidently share one FHIR platform. Recorded verbatim as served. It has
        no practical effect because the formulary API is unauthenticated, but a client that blindly
        followed SMART discovery from this base would authenticate against the wrong brand.
  capabilities:
    - client-public
    - sso-openid-connect
    - launch-standalone
    - client-confidential-symmetric
    - context-standalone-patient
    - permission-offline
    - permission-patient
  capability_reading: >-
    client-public plus client-confidential-symmetric means both public (PKCE-protected) and
    confidential (shared-secret) clients are supported. launch-standalone plus
    context-standalone-patient means standalone launch with a single patient context — there is no EHR
    launch. permission-offline confirms refresh tokens via offline_access. permission-patient confirms
    patient/*.* scopes. There is no permission-user and no permission-system, so there is no
    provider-facing or backend-services (SMART Backend Services / client_credentials) surface.
  absent:
    - registration_endpoint      # no dynamic client registration
    - introspection_endpoint
    - revocation_endpoint
    - grant_types_supported
    - scopes_supported
    - code_challenge_methods_supported
  absent_note: >-
    The three documents carry only authorization_endpoint, token_endpoint and capabilities. SMART App
    Launch treats several of the missing fields as recommended, so this is a thin discovery document
    even by its own specification.
token_lifetime:
  published: false
  note: >-
    Neither the smart-configuration documents nor any public page states an access-token lifetime.
    Request offline_access and refresh on a 401 rather than on an assumed expiry.
registration:
  url: https://devportal.ibx.com/cmssignin/
  process: >-
    Register the company and each member-facing application in the developer portal, then activate the
    account. Credentials are issued per registered application. Developer Portal Terms section 3: IBC
    may revoke credentials used with an application or product not registered with IBC.
  support: mailto:AppOnboardingSupport@ibx.com
  gated: true
  gated_note: >-
    devportal.ibx.com renders entirely in JavaScript and returns no readable content to a non-executing
    client, so the post-registration auth documentation could not be read by this pass.
oidc_discovery:
  served: false
  probed:
    - url: https://eapics.ibx.com/.well-known/openid-configuration
      status: 404
    - url: https://eapics.ibx.com/patient/v1/fhir/.well-known/openid-configuration
      status: 404
    - url: https://eapics.ibx.com/.well-known/oauth-authorization-server
      status: 404
    - url: https://eapics.ibx.com/patient/v1/fhir/.well-known/oauth-authorization-server
      status: 404
    - url: https://eapics.ibx.com/patient/v1/fhir/.well-known/oauth-protected-resource
      status: 404
  note: >-
    The sso-openid-connect capability is advertised but no OIDC discovery document and no RFC 8414
    authorization-server metadata is served anywhere. member.ibx.com — which hosts the authorization
    endpoint — returns 403 to every anonymous request, so its metadata could not be probed either.