Singpass Login Laravel Package

Technical Evaluation

Architecture Fit The package now supports FAPI 2.0 (Financial-grade API) and CorpPass, expanding its use case from SingPass-only authentication to broader government/corporate identity ecosystems. This aligns well with Laravel-based systems requiring OAuth2/OpenID Connect (OIDC) with enhanced compliance (e.g., financial services, enterprise SSO). The addition of strict typing and PHPStan coverage suggests improved robustness for large-scale deployments.

Integration Feasibility

• High for Laravel: The package remains PHP-centric and leverages Laravel’s service provider/guard patterns, ensuring seamless integration with existing auth stacks (e.g., Auth::guard('singpass')).
• FAPI 2.0/CorpPass: Requires validation of token binding, MTLS, and advanced consent flows—may need custom middleware or API gateway adjustments if relying on legacy OAuth1/OIDC endpoints.
• Dependency Updates: Minor version bumps (e.g., web-token/jwt-framework) are low-risk, but GitHub Actions upgrades (v5→v7) could impact CI/CD pipelines if using custom workflows.

Technical Risk

• Breaking Changes:
  • Strict Types: May expose type errors in downstream Laravel apps if not already using declare(strict_types=1).
  • FAPI 2.0: New endpoints/methods (e.g., CorpPass::authenticate()) could require backward-compatible aliases or wrapper classes to avoid breaking existing code.
  • CI/CD: Actions cache/upload-artifact updates may break workflows if not explicitly tested.
• Performance: PHPStan coverage maxing could slow local dev environments but is negligible in production.
• Security: FAPI 2.0 introduces stricter token validation—audit existing token handling (e.g., jwt-framework upgrades) for compliance.

Key Questions

1. Does the target Laravel app use OAuth1/OIDC or pure SingPass? If the former, FAPI 2.0 may require dual-auth flows.
2. Are there custom token validators or third-party auth services (e.g., Passport) that need alignment with FAPI 2.0’s token binding?
3. What’s the CI/CD maturity? GitHub Actions v7+ may need testing for artifact caching or workflow parallelism.
4. How critical is backward compatibility? If v2.x is in production, plan for feature flags or parallel deployment.

Integration Approach

Stack Fit

• Laravel 8+/9+: Ideal for FAPI 2.0/CorpPass due to built-in HTTP client improvements and PSR-15 middleware support.
• Legacy Laravel (5.8–7.x): Possible but may require polyfills for strict types or updated dependencies (e.g., web-token/jwt-framework).
• Non-Laravel PHP: Limited utility; package is tightly coupled to Laravel’s Auth facade and service containers.

Migration Path

1. Pre-Upgrade:
   • Enable strict_types=1 in bootstrap/app.php and test for type errors.
   • Audit token handling code for FAPI 2.0 compliance (e.g., token_binding headers).
   • Update CI/CD workflows to use GitHub Actions v7+ (if applicable).
2. Upgrade:
   • Replace composer.json dependency ("accredifysg/singpass-login": "^3.0").
   • Publish new config (config/singpass.php) if using CorpPass (new corppass section).
   • Extend AuthServiceProvider to register CorpPass guard:

     $this->app['guard']->extend('corppass', function ($app) {
         return new CorpPassGuard($app['auth']->createUserProvider(), $app['request']);
     });
     

3. Post-Upgrade:
   • Test FAPI 2.0 flows with token binding and MTLS (if applicable).
   • Validate CorpPass endpoints in staging.

Compatibility

• Laravel: ≥8.0 recommended (strict types, PSR-15).
• PHP: ≥8.0 (strict types requirement).
• Dependencies: Minor updates to jwt-framework, phpstan are safe; GitHub Actions bumps may need workflow adjustments.

Sequencing

1. Phase 1: Upgrade package in a non-production branch; test SingPass flows.
2. Phase 2: Implement CorpPass guard and FAPI 2.0 validation.
3. Phase 3: Roll out CI/CD updates (Actions v7+).
4. Phase 4: Gradually migrate traffic to new auth flows.

Operational Impact

Maintenance

• Pros:
  • Strict types reduce runtime errors.
  • PHPStan catches edge cases early (e.g., undefined array keys).
  • FAPI 2.0 aligns with modern OIDC standards, reducing future deprecation risk.
• Cons:
  • CorpPass/SingPass divergence: May require dual-configuration or feature flags.
  • CI/CD overhead: GitHub Actions updates may need maintenance for caching strategies.

Support

• Debugging: Strict types and PHPStan improve error messages but may increase local dev friction.
• FAPI 2.0: New token validation logic could introduce support tickets if not documented (e.g., token_binding failures).
• Deprecations: Monitor jwt-framework and web-token for future breaking changes.

Scaling

• Performance: Minimal impact; FAPI 2.0 adds negligible overhead if using Laravel’s HTTP client.
• Load Testing: Validate CorpPass/SingPass token exchange rates under high traffic (FAPI 2.0 may introduce additional cryptographic ops).
• Database: No schema changes, but user metadata (e.g., CorpPass attributes) may need new columns.

Failure Modes

Ramp-Up

• Dev Onboarding:
  • Document FAPI 2.0 vs. OIDC differences.
  • Provide CorpPass/SingPass quickstart guides with sample config.
• QA Focus:
  • Test token binding with malformed requests.
  • Validate strict types in edge cases (e.g., null returns).
• Training:
  • Highlight PHPStan as a dev tool (not a blocker).
  • Train ops on FAPI 2.0 token validation logs.