Skip to content

Commit

Permalink
Create session-managment
Browse files Browse the repository at this point in the history
  • Loading branch information
Rajdip019 authored May 13, 2024
1 parent 5dab887 commit 06e6ca6
Showing 1 changed file with 47 additions and 0 deletions.
47 changes: 47 additions & 0 deletions docs/backend/session-managment
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@

# Session Managment

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


## Tokens issues for a session

The 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. A ID token is lived for 1 hour.
- `Refresh Token` : Holds the capability to refresh the session. A refresh token lives for 45 days. Although 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 verifing a session form `session/verify` route. We check if the ID Token is valid and not expired. If both satisfied it returns user data which you can store in a user state.

## Refresh Session

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

The next we validate if the user agent for the session is same or not. If not then we revoke the session and mails 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 consicutive failed attempted sign in count and block the user for sometime based on that and also sends an email to the user about that and gives the device info as well which device is trying to do this.

- 5 consicutive wrong password - 180 seconds block
- 10 consicutive wrong password - 600 seconds block
- 15 consicutive wrong password - 3600 seconds block

For now there is no rate limiting by the server it self we highly recomend you to 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 user that can be used to signout from all devices / bfrowser of the user.

## Feedback

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

0 comments on commit 06e6ca6

Please sign in to comment.