Authentication & Identity Management Guide

Core Identity Resolution

Establishing Client Context

Initiate sessions by resolving client identity through our foundational query:

query ClientIdentityCheck {
  Me {
    reference  # Returns "ResourceType/ID" format
    resourceType
  }
}

Sample Response:

{
  "data": {
    "Me": {
      "reference": "Practitioner/def456",
      "resourceType": "Practitioner"
    }
  }
}

Security Configuration Essentials

Authentication Blueprint

{
  "hostname": "api.healthsystem.com",
  "auth": {
    "systems": [{
      "type": "oauth",
      "parameters": {
        "jwks_uri": "https://b2cinstance.b2clogin.com/policy/openid-configuration",
        "issuer": "https://b2cinstance.b2clogin.com/tenant-id/v2.0/"
      }
    }]
  },
  "fhir": {
    "base_url": "https://fhir-cluster.azurehealthcareapis.com"
  },
  "rbac": {
    "default_access": "Forbidden",
            {
                "client_role": "Patient",
                "entity_name": "Patient",
                "operation": "create",
                "validator": "patient_compartment"
            },
    ]
  }
}

Authentication Workflows

Identity Architecture

SMART on FHIR Implementation

Our system implements SMART on FHIR framework for:

• Granular scopes: patient/*.read practitioner/Observation.write
• Contextual launch sequences
• EHR-agnostic authorization

Role-Resource Mapping:

Role Type	FHIR Resource	Access Scope	Token Lifetime
Patient	Patient	Own data access	1 hour
Practitioner	Practitioner	Department-level access	8 hours
Device	Device	Specific resource writes	24 hours
RelatedPerson	RelatedPerson	Specific data access	1 hour

Token Management

JWT Claim Mapping

{
  "extension_role": "Practitioner",
  "extension_fhir_id": "def456...",
  "scopes": "patient/Observation.read practitioner/Patient.write"
}

Validation Process:

1. Verify token signature via JWKS endpoint
2. Match claims to FHIR resources
3. Apply RBAC validation rules
4. Generate audit trail entry

Identity Resolution Flow

Security Headers Specification

Header	Purpose	Example Value
Authorization	Bearer token	Bearer eyJhbGci...
X-Request-Context	Audit metadata	{"department": "cardiology"}
Content-Type	Payload format	application/json
If-Match	Optimistic locking	W/"version-id"

Best Practices

1. Token Management

   • Rotate secrets every 90 days
   • Use proof-key exchange (PKCE) for mobile clients
   • Implement token binding for sensitive operations

2. Role Configuration

   "validation_rules": [
      {
        "client_role": "Patient",
        "entity_name": "Patient",
        "operation": "create",
        "validator": "patient_compartment"
      }

]

3. **Audit Logging**
- All authentication attempts logged with geolocation
- Failed attempts trigger alerting after 3 failures
- Success logs include accessed resource types