-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
47 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |