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

New issue

Open

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

gitea-mirror commented

2026-05-23 08:38:03 -06:00

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

gitea-mirror commented

2026-05-23 08:38:06 -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!

@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!

gitea-mirror commented

2026-05-23 08:38:07 -06:00

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:
@.***>

@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: > ***@***.***> >

gitea-mirror commented

2026-05-23 08:38:08 -06:00

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.

@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.

gitea-mirror commented

2026-05-23 08:38:09 -06:00

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?

@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?