[GH-ISSUE #12] Ability to add custom authentication function #6

Open
opened 2026-05-23 08:38:03 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @trenta3 on GitHub (Apr 22, 2022).
Original GitHub issue: https://github.com/appy-one/acebase-server/issues/12

I would like to use a custom authentication function for users.
My use case consists in having the user_ids be public keys, and I would like to authenticate them by challenging them to encrypt via their private key a short random string, and checking on the server that it can be decrypted via their ids (corresponding to the public key).

I did not find any mention of it being possible in the documentation, but I am confident it shouldn't be too hard to do.
And thank you for all the effort into developing such a beautiful piece of code!

Originally created by @trenta3 on GitHub (Apr 22, 2022). Original GitHub issue: https://github.com/appy-one/acebase-server/issues/12 I would like to use a custom authentication function for users. My use case consists in having the user_ids be public keys, and I would like to authenticate them by challenging them to encrypt via their private key a short random string, and checking on the server that it can be decrypted via their ids (corresponding to the public key). I did not find any mention of it being possible in the documentation, but I am confident it shouldn't be too hard to do. And thank you for all the effort into developing such a beautiful piece of code!
gitea-mirror added the
feature request
label 2026-05-23 08:38:03 -06:00
Author
Owner

@appy-one commented on GitHub (Apr 29, 2022):

That sounds like a nice addition! I would not use the user id as public key though, I'd add a new user field public_key that allows one to change their keys later. Signing in would then require 2 new endpoints to start (challenge) and finish (check) the sign in. If you would like to implement this yourself, let me know!

<!-- gh-comment-id:1113401230 --> @appy-one commented on GitHub (Apr 29, 2022): That sounds like a nice addition! I would not use the user id as public key though, I'd add a new user field `public_key` that allows one to change their keys later. Signing in would then require 2 new endpoints to start (challenge) and finish (check) the sign in. If you would like to implement this yourself, let me know!
Author
Owner

@trenta3 commented on GitHub (Apr 29, 2022):

Glad you liked it. It seems good to me to add a field to user records, and
maybe to give a default implementation, but otherwise I feel that it is
necessary to leave the ability to customize such functions to the developer
due to the wide variety of keys types (factorisation, elliptic curves or
lattice-based) and the various kinds of checks that can be performed
(diffie-hellman, message signing, etc).

I am still getting familiar with the codebase and I don't have a clear idea
of where I would implement those functions.

Il ven 29 apr 2022, 16:38 Ewout Stortenbeker @.***> ha
scritto:

That sounds like a nice addition! I would not use the user id as public
key though, I'd add a new user field public_key that allows one to change
their keys later. Signing in would then require 2 new endpoints to start
(challenge) and finish (check) the sign in. if If you would like to
implement this yourself, let me know!


Reply to this email directly, view it on GitHub
https://github.com/appy-one/acebase-server/issues/12#issuecomment-1113401230,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACSTYELZZDYSIPSFNCLSRULVHPX75ANCNFSM5UDN7WPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

<!-- gh-comment-id:1113642691 --> @trenta3 commented on GitHub (Apr 29, 2022): Glad you liked it. It seems good to me to add a field to user records, and maybe to give a default implementation, but otherwise I feel that it is necessary to leave the ability to customize such functions to the developer due to the wide variety of keys types (factorisation, elliptic curves or lattice-based) and the various kinds of checks that can be performed (diffie-hellman, message signing, etc). I am still getting familiar with the codebase and I don't have a clear idea of where I would implement those functions. Il ven 29 apr 2022, 16:38 Ewout Stortenbeker ***@***.***> ha scritto: > That sounds like a nice addition! I would not use the user id as public > key though, I'd add a new user field public_key that allows one to change > their keys later. Signing in would then require 2 new endpoints to start > (challenge) and finish (check) the sign in. if If you would like to > implement this yourself, let me know! > > — > Reply to this email directly, view it on GitHub > <https://github.com/appy-one/acebase-server/issues/12#issuecomment-1113401230>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACSTYELZZDYSIPSFNCLSRULVHPX75ANCNFSM5UDN7WPQ> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
Author
Owner

@trenta3 commented on GitHub (Apr 29, 2022):

If you can point me to relevant files and just give a couple of
instructions about code style I will give it a try.

<!-- gh-comment-id:1113648428 --> @trenta3 commented on GitHub (Apr 29, 2022): If you can point me to relevant files and just give a couple of instructions about code style I will give it a try.
Author
Owner

@appy-one commented on GitHub (May 6, 2022):

I think the easiest way to go about this is if you can provide code that:

  • Generates a challenge for the client, preferably in TypeScript. Eg: a function createChallenge that returns (a promise of) a ChallengeRequest object, which contains all necessary details for the client such as the random string to sign/encrypt, method to use etc.
  • Signs a challenge client-side with their private key in a function that returns (a promise of) a ChallengeResponse object that can be sent back to the server
  • Checks a challenge response server-side with a function that accepts a public key, ChallengeRequest and ChallengeResponse, and returns (a promise of) a boolean indicating if the check passed.

I will then handle the implementation of those into server routes and client requests.

What do you think?

<!-- gh-comment-id:1119460775 --> @appy-one commented on GitHub (May 6, 2022): I think the easiest way to go about this is if you can provide code that: * Generates a challenge for the client, preferably in TypeScript. Eg: a function `createChallenge` that returns (a promise of) a `ChallengeRequest` object, which contains all necessary details for the client such as the random string to sign/encrypt, method to use etc. * Signs a challenge client-side with their private key in a function that returns (a promise of) a `ChallengeResponse` object that can be sent back to the server * Checks a challenge response server-side with a function that accepts a public key, `ChallengeRequest` and `ChallengeResponse`, and returns (a promise of) a boolean indicating if the check passed. I will then handle the implementation of those into server routes and client requests. What do you think?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
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: github-starred/acebase-server#6
No description provided.