Step-by-Step Process & Entities

Entities Involved

1. ApiService

• The core backend API
• Location: Source/EGU.PartnerPortal.ApiService
• Calls IntegrationServiceAPI for external system integrations
• Validates tokens when IntegrationServiceAPI calls it

2. ServiceTokenHandler (Middleware)

• HTTP message handler that intercepts outgoing requests
• Location: Source/EGU.PartnerPortal.ApiService/Middleware/Handler/ServiceTokenHandler.cs
• Automatically gets tokens from Azure AD
• Attaches tokens to requests going to IntegrationServiceAPI

3. Microsoft Entra ID (Azure AD Tenant)

• Microsoft's cloud identity service
• Tenant ID: 6073ce8b-73f3-4df4-9b80-5e40cdc6965f
• Issues tokens for service-to-service communication
• Validates client credentials (client ID + client secret)

4. IntegrationServiceAPI

• External system integration API
• Location: Source/EGU.PartnerPortal.IntegrationServiceAPI
• Calls ApiService to create/update work orders and instructions
• Validates tokens when ApiService calls it

High-Level Authentication Flow

┌─────────────────────────────────────────────────────────────────┐
│       SERVICE-TO-SERVICE AUTHENTICATION FLOW                    │
└─────────────────────────────────────────────────────────────────┘

    ┌──────────────────┐
    │   ApiService     │
    │   (Needs to call │
    │   Integration)   │
    └────────┬─────────┘
             │
             │ Step 1: Make API call
             │ (e.g., send XML message)
             ▼
    ┌──────────────────────────┐
    │  ServiceTokenHandler     │
    │  (Middleware)            │
    └────────┬─────────────────┘
             │
             │ Step 2: Need token first!
             │ Request token from Azure AD
             │ Sends:
             │  - Client ID
             │  - Client Secret
             │  - Scope
             ▼
    ┌──────────────────────────────┐
    │  Microsoft Entra ID          │
    │  Token Endpoint              │
    └────────┬─────────────────────┘
             │
             │ Step 3: Azure AD validates
             │  ✓ Client ID exists
             │  ✓ Client secret matches
             │  ✓ Service has permission
             ▼
    ┌──────────────────────────────┐
    │  Azure AD Returns Token      │
    │  (for IntegrationServiceAPI) │
    └────────┬─────────────────────┘
             │
             │ Step 4: Token attached to request
             │ Authorization: Bearer eyJ...
             ▼
    ┌──────────────────────────────┐
    │  IntegrationServiceAPI       │
    │  Validates Token             │
    └────────┬─────────────────────┘
             │
             │ Step 5: Token validation
             │  ✓ Signature valid
             │  ✓ Issuer correct
             │  ✓ Audience correct
             │  ✓ Not expired
             ▼
    ┌──────────────────────────────┐
    │  ✅ Process Request           │
    │  Execute API logic           │
    │  Return Response             │
    └──────────────────────────────┘

Bidirectional Communication

Both Services Call Each Other

The authentication works in both directions:

Direction 1: ApiService → IntegrationServiceAPI

• ApiService sends work orders, XML messages, completion notifications
• Uses ApiService's client credentials (ID + secret)
• Gets token for IntegrationServiceAPI audience
• Token proves "I am ApiService and I can call IntegrationServiceAPI"
  
  

Direction 2: IntegrationServiceAPI → ApiService

• IntegrationServiceAPI creates/updates work orders, instructions
• Uses IntegrationServiceAPI's client credentials (ID + secret)
• Gets token for ApiService audience
• Token proves "I am IntegrationServiceAPI and I can call ApiService"

Same Process, Different Credentials

The authentication flow is identical in both directions:

• Same steps (1-7 below)
• Same token lifetime (1 hour)
• Same caching mechanism
• Same validation process
  
  

Only the credentials differ:

Why Bidirectional?

ApiService calls IntegrationServiceAPI when:

• Sending work order to external system
• Sending completion notification
• Sending cancellation notice

IntegrationServiceAPI calls ApiService when:

• Receiving work order from external system
• Receiving instruction from external system
• Updating work order status

Each service authenticates itself when making the call, proving its identity to the other service.