ADR-0016 Authentication and Authorization

Publication Date2021-05-14
Last Update2021-05-14
StatusAccepted

Context

In ADR 0006 a decision was made to use the Firebase platform to build the client-facing applications. This platform includes the Firebase Auth component which provides backend services, SDKs, and ready-made UI libraries for account management and authentication.

Even using a drop-in framework like this we need to understand how accounts will be created and how permissions will be granted.

We identified the following requirements for the three use cases:

UC1: VR Designer

  • Account creation and permission granting will be done by eTryOn staff.
  • Data configuration will be done by Brand staff.
  • No creation of accounts possible through Ux.

UC2: Dress Me Up

  • No brand staff accounts needed.
  • eTryOn staff accounts and permissions will be created manually.
  • Data configuration will be done through CLI by eTryOn staff.
  • End users (influencers) need a registration Ux for account creation.
  • No permissions granting / account approval step needed for end users.

UC3: Magic Mirror

  • No brand staff accounts needed.
  • eTryOn staff accounts and permissions created manually.
  • Data configuration done through CLI by eTryOn staff.
  • End users (shoppers) need a registration Ux for account creation.
  • No permissions granting / account approval step needed for end users.

Decision

We will implement UI for end users (influencers) to sign up for an account in the Dress Me Up app.

We will implement UI for end users (shoppers) to sign up for an account in the Magic Mirror app.

We will create IAM accounts with appropriate permissions for eTryOn staff to perform administrative tasks (data configuration for Dress Me Up and Magic Mirror apps, brand user account creation for VR Designer app).

The applications will be single tenant. We will not implement group membership and management within an app.

Consequences

Using Firebase Auth and the supported SDKs makes it easy to implement UI components for sign-up and sign-in, and for the client applications to interact with server-side Firebase components.

We will have to define authorization rules for Cloud Storage and Cloud Firestore to control user access to resources.

When Cloud Functions are called directly from one of our apps, the auth token will be validated automatically but we may need to implement authorization checks in the function itself.

It is not clear from the Firebase Auth documentation that we will be able to prevent a malicious user from accessing Firebase backend services to self-register an account, even when we do not provide a UI for this. If it is not possible to disable those backend APIs we will have to ensure that accounts created in this way have no privileges within the system. This is an area requiring more research.