Leonardo Almada
Back to Work

ACADEMIC TEAM PROJECT

Academic platform with centralized authentication

An academic project under development by a team of four, with OAuth2 SSO, integrated services, and automation for environments and validation.

Team
4 members
Context
Academic project
Status
Under development
Role
Development within a team of 4 members
Evidence
verified private commits, PRs, tests, and CI
Conceptual representation of the system shared by a team of 4 members: applications and services share identity through centralized authentication; it does not represent the real topology or individual authorship of the architecture.
Conceptual representation of the system shared by the team of 4 members. It communicates the identity relationship between applications, services, and centralized authentication; it does not describe the real topology or imply individual authorship of the entire architecture.

Context and problem

The project is a platform made up of several components that need to share identity and collaborate without becoming a single monolithic application.

One of its central problems is authentication: different services need to trust a common identity and maintain a consistent flow for authorization, sessions, and tokens.

At the same time, the project includes functional integrations between services and requires a team to be able to start and validate an environment spanning several repositories.

It is an academic project carried out by four team members, so the contributions described here refer specifically to work I can attribute to myself through code, commits, PRs, and tests.

My contributions

My contributions focus on four areas: centralized authentication, an integration between purchases and a wallet, parts of the frontend, and infrastructure/development tooling.

I do not attribute the design or complete implementation of the platform to my individual work.

An additional challenge of teamwork was maintaining clear interfaces between components and being able to validate changes without relying on all services being developed by the same person.

An academic project under development by a team of four: shared platform and architecture, four areas of verified personal contributions, and testing and CI as validation across those areas.
Derived, sanitized conceptual diagram. The project belongs to a team of four; only verified personal contributions are shown. The platform and its architecture are shared work, and testing and CI are presented as validation across the areas, rather than a fifth area of authorship.

Centralized authentication

I worked on implementing the SSO system using Laravel Passport and OAuth2.

The flow uses Authorization Code with PKCE and covers consent, session and token handling, and global logout.

The intention is for different clients to delegate authentication to a central service without sharing credentials directly between applications.

As a conceptual reference for the public standard, the authorization request includes the PKCE challenge; for the exchange, the client presents the code and verifier. The server verifies PKCE before issuing tokens. Subsequent session management depends on the application; OAuth2 and PKCE do not define it on their own.

Conceptual OAuth2 Authorization Code with PKCE sequence: client, request with challenge, server, code, verification with code and verifier, token exchange, and authenticated session as an application-level step.
Derived, sanitized conceptual sequence of a public standard, independent of platform authorship. The client sends the challenge in the request and presents the code and verifier for the exchange; the server verifies PKCE before issuing tokens. Subsequent session management belongs to the application and is not guaranteed by OAuth2/PKCE. It does not represent real topology or configuration, or attribute the entire platform to one person.

Purchase ↔ Wallet integration

Another significant contribution was the integration flow between the purchase process and the wallet.

The problem here involved more than making a request between two services. States had to be modeled, and the same operation had to be prevented from being applied more than once during repetitions or retries.

That is why the flow incorporates considerations of idempotency, explicit states, and integration tests using mocks where appropriate.

Frontend

I also worked on React frontend components related to inventory.

This included API integration and interface behavior such as filters and pagination.

Infrastructure and workflows

Working across several repositories raised another problem: setting up a consistent development environment.

I worked on automation with Docker Compose and Bash to facilitate a fresh bootstrap of the environment, service persistence, and guards intended to prevent invalid states during preparation.

Part of this work also integrates with CI and end-to-end tests.

Testing and CI

Authentication and integration flows are backed by implementation and tests; the purchase and wallet area also has a dedicated automated suite.

The dedicated purchase and wallet suite reached 27 tests and 99 assertions, used alongside CI to validate behavior.

Validation, results, and status

The contributions described can be traced to specific changes within the project's repositories.

The infrastructure can be rebuilt using the tooling prepared for bootstrap, reducing the number of manual steps needed to start from a clean environment.

Under development. The project remains under development, so this case is not presented as a finished product. Its value in the portfolio lies in showing verifiable technical contributions made within a multi-service architecture and a team.

What it demonstrates

  • Working with OAuth2 and SSO within a multi-service platform.
  • Addressing service integration, idempotency, and testing.
  • Integrating a React frontend with APIs, filters, and pagination.
  • Automating a multi-repo environment.
  • Working within a shared codebase and clearly distinguishing between the team's work and my own contributions.

Technology and evidence

  • Laravel
  • React
  • Docker Compose
  • Bash

Primary technology: Laravel · Laravel Passport · OAuth2 · Authorization Code + PKCE · React · Docker Compose · Bash · testing · CI/E2E.

Verified evidence: Private repositories · attributable commits and PRs · tests · CI workflows · inspected implementation.

The evidence supports the contributions described, but the repositories are not currently presented as public code.

Privacy note

SANITIZED CASE STUDY

The project is under development and its repositories remain private. The portfolio presents only personal contributions already verified through PRs, commits, tests, and CI, without claiming the team's entire work as my own or exposing private code or configuration.