[FEATURE] Auth unified flow

[hazzo]

What problem are you trying to solve?

We keep doing new projects with an undefined authentication flow to be used across the whole project. We keep reinventing the wheel on each new project we start and keep taking as reference previous executions that are not correctly crafted. We don't have a main reference on how to do a correct and mature authentication flow for a user on a developed web/app.

Why should we solve it?

Tackling this issue will guarantee us not to spent valuable time in a process that's quite trivial but important at the same time for every project. Also we will establish a proper way of doing an authentication flow for all technologies (PHP, Django, JavaScript, Dart) that must work as reference for future newcomers to the company and avoid misunderstandings or lack of knowledge.

How do you propose to solve it?

The idea is to have a set of documents and interfaces for each language stating the contract that should exist between back end and front end. Later once contracts are approved by all parties this must help as guidance to create a demo repository showing how integration is done for future projects and developers. Also it must work as a live example deployed in an internal server for developers and managers to test it.

The Authentication flow should cover the following use cases:

What could go wrong?

We could stall and spend a long time discussing or trying to take paths that are faraway from "the correct ways" already investigated by the software community. We should mark our style without diverging too much of what's done in the software development scene.

Implementation

• [x] #3
• [ ] Review contracts
• [ ] Decide first live example language pair. And track in new issue.

[hazzo]

@Copperfield @ppalomera @jherencia any thoughts? Should I start suggesting tasks? Should we first discuss if the proposed flow It's the correct? It will be great if we can push this repository on a weekly basis.

[jherencia]

Thank you @hazzo, I like the initiative.

My proposal is to follow these steps:

1. Decide the format we are going to use to represent the "contract".
2. Split the flow in parts and prioritize them to start working: e.g: register, login, etc
3. Work on the first pair of implementations (backend + front, eg: python + js) with all the common tools we use in the company: CI, CD, testing environments, monitoring, etc
4. Battle test the first implementation by using it in a project with real traffic and end users
5. Iterate and work on other languages / implementations

For the first step "how do we represent a contract", what ideas do you have in mind?

Thinking high, I suggest to have a unique repository for the "authentication-flow" with:

• README.md
• contract/login.md (I like apiary approach: https://apiary.io/how-apiary-works)
• examples (like https://github.com/vercel/next.js/tree/canary/examples)
• examples/fastapi
• examples/vanilla-js
• examples/django
• examples/symfony

[hazzo]

Great @jherencia!. Thanks! I'll go point by point:

1. Totally agree (details at the end)
2. You mean splitting for the "contract" step or for every step? Ex: Login -> Contract -> Implementation -> Test? I think this will slow us down. I rather split contracts and once contracts are finished implement all the agreements in one language.
3. Agree, we could start react + fastapi? @Copperfield @ppalomera
4. Agree too (maybe incoming projects should suggest us with what technology we should start first)
5. Agree too

Regarding "how do we represent a contract", my idea it's kind of similar but with some differences.

I think that in this repository, in it's corresponding dir (features/authentication), we should have the contracts. I like the apiary example. It would be great to use some pseudo code to define the objects that take part of the contract (input and outputs). We could simply use JSON format which it's a common standard. And example could be:

# Basic login API

# login [/login]
This resource represents a basic login.

## Login [POST]
The password should follow the following regex /^(?=.{8,}$)(?=.*[A-Z])(?=.*[a-z])(?=.*[0-9]).*/

* Body
{
  "email": "foo@mrmilu.com",
   "password": "Secret123&"
}

+ Response 200 (application/json)
null

Once all contracts are stablished, I would kickstart a new repository for each language (front separated from back) depending the first stack we would like to work first (react + django, flutter + symphony, etc). In this repositories we will have all future implementations with their correct usages as a standalone project. This means CI/CD, linters, architecture, etc + future features like authentication. This way we could track with PRs to each project and associate them to this issue and have a final usable example.

Putting here the examples/implementations I think will make the repository diverge from the main focus that it's to discuss and find rock solid solutions to our problems.

In this line, some possible future issues we might like to solve:

• features/error_handling
• features/file_upload
• process/git_flow
• process/environments etc

(This are just ideas)

[jherencia]

About step 2, sorry my proposal was to finish all contracts before any implementation, but to split the discussion per feature.

I do not have concerns on splitting the contract from its implementations. So if everybody is on board, let's get started.