Aller au contenu

Barrin's Identity Platform: Future Architecture Proposal

Status: Future consideration

Version: 1.0

Audience:

  • Solution Architect
  • Backend developers
  • Frontend developers
  • DevOps
  • Product owner

1. Purpose

This document describes a possible future evolution of the Barrin's ecosystem authentication architecture.

The objective is to define a migration path from a shared authentication implementation inside Barrin's API toward a dedicated identity application.

This document is not an implementation requirement.

The migration must only happen when justified by ecosystem growth.

2. Context

The Barrin's ecosystem is expected to contain multiple applications.

Current applications:

  • Barrin's API
  • Tamiyo Scroll

Future applications may require:

  • user accounts;
  • authentication;
  • user profiles;
  • preferences;
  • permissions.

Implementing authentication independently inside every application would create:

  • duplicated code;
  • duplicated user interfaces;
  • inconsistent user experience;
  • increased security maintenance cost.

3. Long-term Vision

The long-term goal is to create a dedicated Barrin's Identity application.

This application would act similarly to:

  • Google Account;
  • GitHub Identity;
  • Microsoft Account.

Its responsibility would be to provide a unified identity layer for all Barrin's applications.

4. Target Architecture

Future architecture:

           Barrin's Identity
                 |
 +---------------+---------------+
 |               |               |
Tamiyo Scroll Barrin's App B Barrin's App C
 |               |               |
 +---------------+---------------+
                 |
            Barrin's APIs

5. Responsibilities of Barrin's Identity

The identity application would own:

Authentication

  • account creation;
  • login;
  • logout;
  • password management;
  • email verification;
  • account recovery;
  • multi-factor authentication (future).

User account management

Centralized user panel:

  • username;
  • email;
  • avatar;
  • preferences;
  • language;
  • security settings;
  • connected applications.

Token management

The identity provider would issue:

  • access tokens;
  • refresh tokens;
  • identity claims.

Applications would validate identity through tokens instead of managing credentials directly.

6. Expected User Experience

Example:

User opens Tamiyo Scroll
 |
Application checks authentication
 |
User redirected to Barrin's Identity
 |
User authenticates once
 |
Identity provider returns token
 |
User returns to Tamiyo Scroll

The same mechanism would apply to all future Barrin's applications.

7. Technical Direction

The preferred standard is:

  • OAuth 2.0
  • OpenID Connect

Barrin's Identity becomes:

OpenID Connect Provider

Applications become:

OAuth Clients

8. Migration Strategy

Phase 1 - Current state

Single account-based application.

Authentication remains inside Barrin's API.

Objectives:

  • keep authentication isolated;
  • avoid application-specific user models;
  • preserve extraction possibility.

No identity platform is created.

Phase 2 - Migration trigger

Migration begins only when:

A second Barrin's application requiring user accounts has been deployed.

The migration should happen after this second application is operational.

Reasons:

  • validate the real need;
  • avoid premature complexity;
  • justify migration effort.

Phase 3 - Identity extraction

Create:

Barrin's Identity

Move progressively:

  • user authentication;
  • registration;
  • email verification;
  • profile management;
  • account settings.

Phase 4 - Application migration

Each application migrates from:

Application
|
Barrin's API authentication

toward:

Application
|
Barrin's Identity
|
Token validation
|
Application API

9. Current Design Requirements

Until migration happens:

Current authentication implementation should remain extractable.

Required:

  • stable user identifier;
  • authentication logic isolated;
  • no duplicated user storage;
  • no application-specific authentication workflow;
  • no frontend-owned authentication rules.

Avoid:

  • implementing OAuth infrastructure too early;
  • creating unnecessary services;
  • increasing current complexity without need.

10. Feasibility Assessment

Technical feasibility

Rating:

★★★★★

The migration is based on mature standards.

OAuth 2.0 and OpenID Connect provide a proven approach.

Architectural feasibility

Rating:

★★★★★

The Barrin's ecosystem can evolve naturally toward this model.

The main requirement is maintaining clean boundaries from the beginning.

Implementation complexity

Rating:

★★★☆☆

A minimal identity service is achievable.

A production-grade identity platform requires significant security and operational work.

11. Cost Estimation

Estimates are approximate.

Minimal identity extraction

Includes:

  • account migration;
  • authentication API;
  • tokens;
  • basic profile.

Estimated:

4–8 weeks.

Complete identity platform

Includes:

  • OpenID Connect;
  • administration;
  • MFA;
  • recovery;
  • audit logs;
  • monitoring;
  • security hardening.

Estimated:

3–6 months.

12. Recommendation

Do not implement Barrin's Identity now.

The recommended strategy:

1. Build clean authentication boundaries today.
2. Migrate only after the second account-based application exists.

This provides:

  • low current complexity;
  • controlled migration cost;
  • consistent future user experience.

13. Final Decision Rule

The identity migration decision should be evaluated when:

  • a second account-based Barrin's application exists;
  • authentication duplication becomes measurable;
  • centralized identity provides clear maintenance benefits.

Until then:

Keep the system simple.

Prepare for extraction.

Do not over-engineer.