BFS Testservice

Multi-Auth Pattern Showcase with APISIX

Three Authentication Patterns:

This service demonstrates three different authentication approaches for modern web applications.

🔐

Session-based Auth

Server-Side Rendered (SSR) application with traditional session cookies. Backend handles all OAuth flows.

Authorization Code Server Sessions HTTP Cookie
Try Session Auth →
🤖

M2M API

Machine-to-Machine authentication with JWT Bearer tokens. For service-to-service communication.

JWT Bearer Client Credentials JWKS Validation
View M2M API →
⚡

SPA with PKCE

Single Page Application with Authorization Code + PKCE flow. No client secret needed.

PKCE Public Client Bearer Token
Try SPA PKCE →

🎛ī¸ Gateway-First Strategy Live Demo

Demonstrate how APISIX controls API access without changing application code. The same endpoint can be public or JWT-protected via APISIX configuration.

Test Endpoint: /api/health

Current APISIX Config: PUBLIC

How to Switch Public ↔ Protected:

1. Public Route (Current) 
# helm/templates/apisix-route-public.yaml
- name: health-check
  match:
    paths:
      - /api/health
  backends:
    - serviceName: testservice
  # NO authentication plugin
2. Protected Route (Add JWT) 
# helm/templates/apisix-route-protected.yaml
- name: health-check
  match:
    paths:
      - /api/health
  backends:
    - serviceName: testservice
  plugins:
    - name: openid-connect
      enable: true
      config:
        bearer_only: true
        use_jwks: true
      secretRef: oauth-client-secret

✨ Zero Code Changes! Same backend code, different APISIX route = different behavior.

Additional Resources:

📚 API Documentation (Swagger) 💚 Health Check ℹī¸ System Information 🎛ī¸ APISIX Dashboard

About This Demo:

This service demonstrates the migration from oauth2-proxy to Apache APISIX API Gateway. All three authentication patterns are configured via APISIX routes with different plugins:

Features: Rate Limiting, CORS, Security Headers, Prometheus Metrics