Navak/navak-backend
5
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

[impl] Authentification #1

New issue
Closed
opened 2026-02-20 13:27:28 +01:00 by yun · 5 comments
yun commented 2026-02-20 13:27:28 +01:00
Owner
Copy link

Make the auth system

Register

  • The only required info to create an account is a username (not even a password).
  • The app should ask (optional) the user for an email address (which is hashed in DB).
    • The email address is used to recover the account (like when changing device or adding a new device)
    • If the user doesn't provide an email address and lose their device, the account is not recoverable
  • With the username (and optional normalized email), the server creates an account and gives the client a session token
    • The session token has an expiration date (3 months? Make configurable?), but it is extended as long as the user is active
      • So if the user isn't active for more than 3 months they will be disconnected (and lose their account if they didn't set an email address)

Login

  • Login is required to gain access to a user account on a new device (or a device unused for 3 months)
  • Login is only possible if the user has set an email address on their account
  • The app asks for the username and the email address
  • The server checks whether
    • the username exists in DB
    • the user has an email address set
    • the entered email address matches the hash present in DB
  • If the checks pass, the server uses the entered email address to send a login URL containing a secret code by email
    • The code is valid for 15 minutes
  • When the user uses the link, they get a new session token for their account
## Make the auth system ### Register - The only required info to create an account is a username (not even a password). - The app should ask (optional) the user for an email address (which is hashed in DB). - The email address is used to recover the account (like when changing device or adding a new device) - If the user doesn't provide an email address and lose their device, the account is not recoverable - With the username (and optional *normalized* email), the server creates an account and gives the client a session token - The session token has an expiration date (3 months? Make configurable?), but it is extended as long as the user is active - So if the user isn't active for more than 3 months they will be disconnected (and lose their account if they didn't set an email address) ### Login - Login is required to gain access to a user account on a new device (or a device unused for 3 months) - Login is only possible if the user has set an email address on their account - The app asks for the username and the email address - The server checks whether - the username exists in DB - the user has an email address set - the entered email address matches the hash present in DB - If the checks pass, the server uses the entered email address to send a login URL containing a secret code by email - The code is valid for 15 minutes - When the user uses the link, they get a new session token for their account
yun self-assigned this 2026-02-20 13:27:28 +01:00
yun added this to the Navak project 2026-02-20 13:27:28 +01:00
endmove commented 2026-02-21 12:39:59 +01:00
Member
Copy link

@yun wrote in #1 (comment):

Make the auth system

Register

  • The only required info to create an account is a username (not even a password).
  • The app should ask (optional) the user for an email address (which is hashed in DB).
    .....

Yo ! Here are a few points to consider and wonder I have.

  1. I fully understand the idea of an account with a simple username and no password (ability to re-auth) -> "invite session" (no restrictions...). But this can cause few problems if poorly managed, such as Sybil attacks, identity theft, etc.. even if it's temporary.
  2. Since the username+email combination becomes the only entrypoint, we will need to think about standardizing/parsing the email before hashing it. (accents, case, ., +, etc..).
    2.1. Should we allow a user to have multiple accounts with the same email address? -> I would say no.
  3. There is a lack of scope definition around session and device management, which is often developed in parallel/at the same time with the auth register/login.

I find the authentication method you came up with quite interesting :D

@yun wrote in https://git.nexlight.be/Navak/navak-backend/issues/1#issue-22: > ## [](#make-the-auth-system)Make the auth system > ### [](#register)Register > * The only required info to create an account is a username (not even a password). > * The app should ask (optional) the user for an email address (which is hashed in DB). > ..... Yo ! Here are a few points to consider and wonder I have. 1. I fully understand the idea of an account with a simple username and no password (ability to re-auth) -> "invite session" (no restrictions...). But this can cause few problems if poorly managed, such as Sybil attacks, identity theft, etc.. even if it's temporary. 2. Since the username+email combination becomes the only entrypoint, we will need to think about standardizing/parsing the email before hashing it. (accents, case, ., +, etc..). 2.1. Should we allow a user to have multiple accounts with the same email address? -> I would say no. 3. There is a lack of scope definition around session and device management, which is often developed in parallel/at the same time with the auth register/login. I find the authentication method you came up with quite interesting :D
yun commented 2026-02-21 13:29:10 +01:00
Author
Owner
Copy link

@endmove wrote in #1 (comment):

I fully understand the idea of an account with a simple username and no password (ability to re-auth) -> "invite session" (no restrictions...). But this can cause few problems if poorly managed, such as Sybil attacks, identity theft, etc.. even if it's temporary.

Hey!
First, credits to @snowcode for the idea, and thanks for your interest in this project!

  • AFAIK Sybil attacks are a problem if each user has an influence on the project. Here, someone creating 10k accounts would be quiet useless for them, don't you think? To limit the issue on our end (avoid filling up the database / DoS attacks) we could add some kind of captcha (or other mean of slowing down account creation) and automatically delete unused account after a defined period.
  • Can you give an example of "identity theft"?
  • Sure, that's why I wrote "normalized email" in the issue, I thought about it while writing and I didn't want to forget so I just wrote it like that. I imagine something like trimming and uppercasing the email address before hashing.
  • As for the accents, i can not assume a mail server would treat jérôme@test.com and jerome@test.com as the same address, so I can't do anything about that safely (thinking about it, I'm not even sure the standard allows accented characters).
  • I agree that users shouldn't be allowed to have multiple accounts with the same email address (just like on most platforms) as it's less confusing for everyone.
  • One session is on one device, so there is no real distinction between them
  • A session is mostly an long, random and secret string, I don't really know what to say about it

Thanks!

@endmove wrote in https://git.nexlight.be/Navak/navak-backend/issues/1#issuecomment-64: > I fully understand the idea of an account with a simple username and no password (ability to re-auth) -> "invite session" (no restrictions...). But this can cause few problems if poorly managed, such as Sybil attacks, identity theft, etc.. even if it's temporary. Hey! First, credits to [@snowcode](https://codeberg.org/snowcode) for the idea, and thanks for your interest in this project! 1. - AFAIK Sybil attacks are a problem if each user has an influence on the project. Here, someone creating 10k accounts would be quiet useless for them, don't you think? To limit the issue on our end (avoid filling up the database / DoS attacks) we could add some kind of captcha (or other mean of slowing down account creation) and automatically delete unused account after a defined period. - Can you give an example of "identity theft"? 2. - Sure, that's why I wrote "normalized email" in the issue, I thought about it while writing and I didn't want to forget so I just wrote it like that. I imagine something like trimming and uppercasing the email address before hashing. - As for the accents, i can not assume a mail server would treat `jérôme@test.com` and `jerome@test.com` as the same address, so I can't do anything about that safely (thinking about it, I'm not even sure the standard allows accented characters). - I agree that users shouldn't be allowed to have multiple accounts with the same email address (just like on most platforms) as it's less confusing for everyone. 3. - One session is on one device, so there is no real distinction between them - A session is mostly an long, random and secret string, I don't really know what to say about it Thanks!
👍 1
endmove commented 2026-02-21 14:26:44 +01:00
Member
Copy link

@yun wrote in #1 (comment):

@endmove wrote in #1 (comment):

I fully understand the idea of an account with a simple username and no password (ability to re-auth) -> "invite session" (no restrictions...). But this can cause few problems if poorly managed, such as Sybil attacks, identity theft, etc.. even if it's temporary.
...

My bad ! thanks to snowcode !

  1. Let me clarify what i ment when I gave the example of "identity theft." Since guest accounts are only identified by a username, I assumed that usernames are unique. It's easy to imagine someone wanting to cause trouble by creating an account with the username "yun," which would then prevent the real "yun" from creating its own account and assigning its email address to it. Or perhaps usernames aren't unique ? But in that case, how can you tell the real "identities" from the fake ones ? A badge for people on temporary accounts ? -> To me, supporting guest account might be a mistake (just my opinion indeed!)
  2. Okay right, I agree with you
  3. I mean that every user will eventually want to revoke a session that they forgot to log out (oupss did I forget to logout? oh no!). So yes, revok all sess works too, but it's too restrictive. Keeping "factual" metadata such as browser type + last activity day/month/year h:m:s seems like a good idea to me, to be able to select a single session to destroy.
@yun wrote in https://git.nexlight.be/Navak/navak-backend/issues/1#issuecomment-65: > @endmove wrote in #1 (comment): > > > I fully understand the idea of an account with a simple username and no password (ability to re-auth) -> "invite session" (no restrictions...). But this can cause few problems if poorly managed, such as Sybil attacks, identity theft, etc.. even if it's temporary. > ... My bad ! thanks to snowcode ! 1. Let me clarify what i ment when I gave the example of "identity theft." Since guest accounts are only identified by a username, I assumed that usernames are unique. It's easy to imagine someone wanting to cause trouble by creating an account with the username "yun," which would then prevent the real "yun" from creating its own account and assigning its email address to it. Or perhaps usernames aren't unique ? But in that case, how can you tell the real "identities" from the fake ones ? A badge for people on temporary accounts ? -> To me, supporting guest account might be a mistake (just my opinion indeed!) 2. Okay right, I agree with you 3. I mean that every user will eventually want to revoke a session that they forgot to log out (oupss did I forget to logout? oh no!). So yes, revok all sess works too, but it's too restrictive. Keeping "factual" metadata such as `browser type` + `last activity day/month/year h:m:s` seems like a good idea to me, to be able to select a single session to destroy.
yun commented 2026-02-21 14:54:33 +01:00
Author
Owner
Copy link

@endmove wrote in #1 (comment):

  1. Yes that might be a problem, but that's like any platform with unique usernames. If your username is already taken you have to use another one. We could use discriminators (like in the old discord) but I think it's more confusing for people ("I'm yun" -> "Which one?") or forces everyone to append a random identifier along with their chosen name ("I'm yun#6419")

  2. Great idea! Session info could definitely be useful. ATM only the session id, user, and creation date are stored It looks like I forgot the sessions table entirely in the first migration But I'll add some fields for the platform, last activity date and an optional custom name. Thanks!

@endmove wrote in https://git.nexlight.be/Navak/navak-backend/issues/1#issuecomment-68: 1. Yes that might be a problem, but that's like any platform with unique usernames. If your username is already taken you have to use another one. We could use discriminators (like in the old discord) but I think it's more confusing for people ("I'm yun" -> "Which one?") or forces everyone to append a random identifier along with their chosen name ("I'm yun\#6419") 3. Great idea! Session info could definitely be useful. ~~ATM only the session id, user, and creation date are stored~~ It looks like I forgot the `sessions` table entirely in the first migration But I'll add some fields for the platform, last activity date and an optional custom name. Thanks!
👍 1
endmove commented 2026-02-21 15:09:16 +01:00
Member
Copy link

@yun wrote in #1 (comment):

@endmove wrote in #1 (comment):

  1. Yes that might be a problem, but that's like any platform with unique usernames. If your username is already taken you have to use another one. We could use discriminators (like in the old discord) but I think it's more confusing for people ("I'm yun" -> "Which one?") or forces everyone to append a random identifier along with their chosen name ("I'm yun#6419")
    ...

It's my pleasure ! I hope beeing able to help project grow, I saw you started the backend in rust at the moment I only have basis with this language but will learn and move forward :)

@yun wrote in https://git.nexlight.be/Navak/navak-backend/issues/1#issuecomment-69: > @endmove wrote in #1 (comment): > > 1. Yes that might be a problem, but that's like any platform with unique usernames. If your username is already taken you have to use another one. We could use discriminators (like in the old discord) but I think it's more confusing for people ("I'm yun" -> "Which one?") or forces everyone to append a random identifier along with their chosen name ("I'm yun#6419") > ... It's my pleasure ! I hope beeing able to help project grow, I saw you started the backend in rust at the moment I only have basis with this language but will learn and move forward :)
❤️ 1
yun changed reference from dev to authentication 2026-02-24 12:13:58 +01:00
yun closed this issue 2026-03-10 08:39:25 +01:00
yun changed title from Authentification to [impl] Authentification 2026-03-10 16:20:49 +01:00
Sign in to join this conversation.
authentication
Branches Tags
Clear current reference
dev
wsbase
authentication
Clear current reference
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Navak
Assignees
Clear assignees
No assignees
yun
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Navak/navak-backend#1
No description provided.