Authenticating...
Skip to main content

0038: Authentication and Authorization for Player API

STATUS​

Accepted

CONTEXT​

We are building a new API to manage Player information in our system. This internal REST API, called Player API, will replace the functionality currently provided by the legacy ad-tracking PHP package. The API will be internal-only, and any external access will continue to go through the existing public services.

This ADR aims to define how authentication and authorization will be handled in the Player API, balancing internal security needs with implementation complexity and reusability of existing infrastructure.

We will also consider the previous ADR 0012: Targeted API Authentication and Authorization to ensure consistency across services.

Considered Options​

Option 1: Amazon Cognito and Laravel Sanctum​

Description:
This option replicates the authentication approach chosen for the Targeted API, using Amazon Cognito for identity management and Laravel Sanctum for token-based API access control.

Pros:

  • Reuses established security patterns across AdGem services.
  • Adopts OAuth standards for future compatibility.
  • Centralized user and token management.

Cons:

  • More complex implementation involving setup and integration of Cognito.
  • Requires wider coordination with existing IAM systems (even if the Player API is internal).

Option 2: Internal Admin Key​

Description:
This approach mirrors the Offer API implementation, using a single internal admin key for internal authentication.

Pros:

  • Fast to implement.
  • No need for external IAM services or SDK integration.
  • Sufficient for internal-only services.

Cons:

  • No user identity tracking — lacks granularity.
  • Harder to scale or manage access per service in the future.

Option 3: IP Whitelisting + Sanctum​

Description:
Combine IP whitelisting (restricted to trusted AWS account ranges) with Sanctum for token-based security.

Pros:

  • Simple and effective for internal-only APIs.
  • Limits exposure to only specific environments (e.g., Data Engineering’s Airflow).

Cons:

  • Static IP dependency; needs manual updates if infrastructure changes.
  • Still lacks user-level auditing or access granularity.
  • Could be bypassed if IPs are compromised.

DECISION​

We will implement authentication for the Player API using a single internal admin key, mirroring the approach used in the Offer API. This solution is sufficient for our current needs since the Player API is internal-only. Once other teams complete the setup of Amazon Cognito, we will revisit this ADR and plan integration with Cognito for improved security and future scalability. This ADR will be superseded once the migration to Cognito is complete, as the current approach is intended to be a temporary solution.

CONSEQUENCES​

  • Fast implementation and minimal integration effort.
  • No user-level identity tracking or granular access control.
  • Limited scalability; future changes will require refactoring when moving to Cognito. It would be like flipping a switch, since will be consuming Cognito to know whose behalf (app/pub) the api is being consumed. So, the api-key header will be deprecated.
  • Security is dependent on the secrecy and management of the admin key.

Risks​

  • If the admin key is leaked or compromised, all internal access is exposed. We decided to use AWS Parameter Store to avoid the store of the password in our local machines or to get leaked while shared among developers.
  • Lack of audit trails for individual users or services accessing the API.
  • Harder to restrict or revoke access for specific internal consumers.

NOTES​

  • This decision should be revisited if the Player API is exposed outside the internal environment.
  • Since the project Player API will be only consumed by the API project, we can easily spot unauthorized access attempts with the http traffic monitor of Datadog.

References​

  • ADR 0012: Targeted API Authentication and Authorization
  • Laravel Sanctum Documentation
  • AWS IP Whitelisting Best Practices

Original Author​

Maria Cornejo

Approval date​

[To be filled]

Approved by​

[To be filled]