Skip to content

Commit

Permalink
Merge branch 'main' of https://github.com/Rajdip019/in-house-auth int…
Browse files Browse the repository at this point in the history
…o debajyotisaha14/refactoring
  • Loading branch information
Debajyoti14 committed May 13, 2024
2 parents 8f2d4dd + 6a7b46c commit 9a7d3eb
Show file tree
Hide file tree
Showing 6 changed files with 236 additions and 7 deletions.
1 change: 0 additions & 1 deletion .github/workflows/rust.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,6 @@ on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

env:
CARGO_TERM_COLOR: always
Expand Down
73 changes: 67 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,70 @@
# In-house-auth
<h1 align='center'>Flexauth</h1>
<h2 align='center'> <b>Your own flexible, blazingly fast 🦀, and secure in-house authentication system.</b><h2>
<div align="center">
<p>

[![forthebadge](https://forthebadge.com/images/badges/built-with-love.svg)](https://forthebadge.com)
![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=for-the-badge)
![GitHub forks](https://img.shields.io/github/forks/Rajdip019/flexauth?style=for-the-badge)
![GitHub Repo stars](https://img.shields.io/github/stars/Rajdip019/flexauth?style=for-the-badge)
![GitHub contributors](https://img.shields.io/github/contributors/Rajdip019/flexauth?style=for-the-badge)
![GitHub last commit](https://img.shields.io/github/last-commit/Rajdip019/flexauth?style=for-the-badge)
![GitHub repo size](https://img.shields.io/github/repo-size/Rajdip019/flexauth?style=for-the-badge)
![Github](https://img.shields.io/github/license/Rajdip019/flexauth?style=for-the-badge)
![GitHub issues](https://img.shields.io/github/issues/Rajdip019/flexauth?style=for-the-badge)
![GitHub closed issues](https://img.shields.io/github/issues-closed-raw/Rajdip019/flexauth?style=for-the-badge)
![GitHub pull requests](https://img.shields.io/github/issues-pr/Rajdip019/flexauth?style=for-the-badge)
![GitHub closed pull requests](https://img.shields.io/github/issues-pr-closed/Rajdip019/flexauth?style=for-the-badge)

</p>
</div>

## Run Locally
## Introduction
Flexauth is a flexible, blazingly fast 🦀, and secure auth system that you can use for your project/company* . Need to add a specific feature as you need? Change the code as you like and deploy it on your servers. Here is the most flexible auth system for all your needs.

Need some features you think might be helpful for others? Raise a PR and we will surely try to bring it live.

## Local Setup:
Here is a documentation for if you want to setup this repo locally - [Local Setup Doc]()

## Backend Documentation:
Link to backend docs - [Backend Doc](https://github.com/Rajdip019/flexauth/tree/main/docs/backend)

## Folder Structure and others:
Link to general docs for this repository - [General Docs]()

**Code of Conduct:**

Please note that we have a code of conduct in place to ensure a welcoming and inclusive community for all contributors. Be respectful and considerate towards others, regardless of background or experience. Harassment or abusive behavior will not be tolerated.

**Get Started:**

Ready to start contributing to Freeflow? Head over to our GitHub repository and fork the project today!


[GitHub Repository Link](https://github.com/Rajdip019/freeflow)

We look forward to your contributions and thank you for helping us make Freeflow the best platform for designers and teams!


<h2 align='center'> Project maintainers </h2>
<table align='center'>
<tr>
<td align="center">
<a href="https://github.com/Rajdip019">
<img src="https://avatars.githubusercontent.com/u/91758830?v=4" width="100;" alt="Debajyoti Saha"/>
<br />
<sub><b>Rajdeep Sengupta</b></sub>
</a>
</td>
<td align="center">
<a href="https://github.com/Debajyoti14">
<img src="https://avatars.githubusercontent.com/u/91759192?v=4" width="100;" alt="Debajyoti Saha"/>
<br />
<sub><b>Debajyoti Saha</b></sub>
</a>
</td>
</tr>
</table>

```
docker compose up
```

Make sure to have docker daemon running and install mongodb compass to see the database running at `localhost:27017`
16 changes: 16 additions & 0 deletions docs/backend/email-system.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Emails

When you start the local server with `docker` or other ways a local SMTP server starts. Generally, we use Gmail / other provider keys in the SMTP server to send emails using the provided email id.

To know more on how to get the Keys for local setup. Check the Local setup readme. [Lcoal Setup Readme](https://github.com/Rajdip019/in-house-auth/blob/main/README.md)


## Diagram

![email-inhouse-auth](https://github.com/Rajdip019/in-house-auth/assets/91758830/7ea341de-f486-42bc-9070-5b9163dbc7e4)


## Feedback

If you have any feedback, please raise an issue or start a discussion. Thank you.

58 changes: 58 additions & 0 deletions docs/backend/password-protection.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@

# Password protection

Password protection is another core functionality for an auth server and we have taken that seriously. Here is a brief on how the password gets salted, hashed, encrypted, and stored in the database.



## Method

They are using multiple hashing algorithms for **protecting passwords**.

### Hashing Algorithms used.
- `Agron`: Hasing and salting - [carte link](https://crates.io/crates/argon2)
- `Sha256` : Final Hashing - [carte link](https://crates.io/crates/sha256)


## Diagram

![password-protection-inhouse-auth](https://github.com/Rajdip019/in-house-auth/assets/91758830/bdee629b-ea6f-4a61-b3a2-989e0fcf2a11)


## Explaination

Here is a step-by-step guide on how it works.

### Step 1:
Raw Password is salted using a random salt created by the `Argon` library. And then hashed which looks like this -

`$argon2i$v=19$m=16,t=2,p=1$S0FVN2NRbHF2RzBzOXBLSg$xLmzkDhV/z9qRPLpD2ybqw`

You can generate and play with argon hashing library configurations here - [Argon2 online](https://argon2.online/)

### Step 2:
The Agron hash is then put into `sha256` again to generate the more random and more random hash. It gives a 256bit hex which looks like this - `16567bc6bf75f0ac224749b27b42487012246768dbb8bce95b8638b6ab826ca01`

### Step 3:
We encrypt the password using the user `DEK` using the `AESGcm256` algorithm and store it in DB this ensures a higher level of secure and unique hex string.

### Step 3:
The auth server has its own `KEK`. This is unique for the server. You can generate it by running the command below from the root of your project. ( Make sure you have cargo installed ) - [How to install cargo](https://doc.rust-lang.org/cargo/getting-started/installation.html)
```
cargo run --bin create_kek
```

### Step 4:
We use the `KEK` to encrypt the `DEK` using the same `AESGcm256` algorithm and store it in DB.

### Step 5: ( Additional )
For additional safety, you can use `GCP KMS`, `AWS KMS` or any other cloud provider for additional safety.



## Feedback

If you have any feedback, please raise an issue or start a discussion. Thank you.

47 changes: 47 additions & 0 deletions docs/backend/session-managment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@

# Session Management

The session management is done in such a way that you can track each and every user session while giving users long-lived sessions on multiple devices. Also, any detected miscellaneous activity leads to revoking the user session.


## Tokens issues for a session

We are using multiple tokens for a **session**.

### Hashing Algorithms used.
- `Session ID`: Each session of a new device/browser makes a new user session and is encrypted by the user `DEK`. For more info. Session ID id is the main session Identifier - [User Data Protection](https://github.com/Rajdip019/in-house-auth/blob/main/docs/backend/user-data-protection.md)
- `ID Token`: Holds the identity of the user. An ID token is lived for 1 hour.
- `Refresh Token`: Holds the capability to refresh the session. A refresh token lives for 45 days. Although the refresh token life is shorted by the ID Token as on refresh token can refresh only one session it is paired with.


## Verify Session

While verifying a session from the `session/verify` route. We check if the ID Token is valid and not expired. If both are satisfied it returns user data which you can store in a user state.

## Refresh Session

In the refresh session first, we ensure that the `ID Token` is already expired, the `Refresh Token` is not expired, and the `ID Token`, `Refresh Token`, and `Session ID` is paired in the same session.

Next, we validate if the user agent for the session is the same or not. If not then we revoke the session and mail the user for malicious activity.

If all goes good then we issue a new pair of `ID Token` and `Refresh Token` and send it back to the user.


## Brute Force protection for Password

We maintain a consecutive failed attempted sign-in count and block the user for some time based on that and also send an email to the user about that and give the device info as well as which device is trying to do this.

- 5 consecutive wrong passwords - 180 seconds block
- 10 consecutive wrong passwords - 600 seconds block
- 15 consecutive wrong passwords - 3600 seconds block

For now, there is no rate limiting by the server itself we highly recommend you do that by using an external service. We will soon implement that natively as well.

## More malicious activity protection
- If a refresh session is asked and the `ID Token`, `Refresh Token`, and `Session ID` are not paired together we revoke the token immediately. Like if a wrong Refresh token or Session ID is passed for a session ID the session gets blocked.

- We also have a revoke-all-session endpoint for users that can be used to sign out from all devices/browsers of the user.

## Feedback

If you have any feedback, please raise an issue or start a discussion. Thank you.
48 changes: 48 additions & 0 deletions docs/backend/user-data-protection.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@

# User Data Protection

Data protection is one of the main things for a auth server and we have taken that seriously. Here is a brief on how the data gets encrypted and stored in the database.



## Method

The method we are using for encryption is **Envelope Encryption**

### Terminology ( to keep in mind )
- `DEK`: Data Encryption Key
- `KEK`: Key Encryption Key


## Diagram

![data-protection-inhouse-auth](https://github.com/Rajdip019/in-house-auth/assets/91758830/163fdd5a-1757-481c-ba18-3a4bfacb72d2)


## Explaination

Here is a step-by-step guide on how it works.

### Step 1:
Every user is assigned a new and unique `DEK` when they sign up.

### Step 2:
We encrypt all the user data from `Session Details`, `Password Reset Request`, and all with the user `DEK` using the `AESGcm256` algorithm and store it in DB.

### Step 3:
The auth server has its own `KEK`. This is unique for the server. You can generate it by running the command below from the root of your project. ( Make sure you have cargo installed ) - [How to install cargo](https://doc.rust-lang.org/cargo/getting-started/installation.html)
```
cargo run --bin create_kek
```

### Step 4:
We use the `KEK` to encrypt the `DEK` using the same `AESGcm256` algorithm and store it in DB.

### Step 5: ( Additional )
For additional safety, you can use `GCP KMS`, `AWS KMS` or any other cloud provider for additional safety.



## Feedback

If you have any feedback, please raise an issue or start a discussion. Thank you.

0 comments on commit 9a7d3eb

Please sign in to comment.