Adding custom algorithm

[Teukros]

I want to use this package in the new project, but in some cases we use our own custom algorithm. Would you accept adding some logic that allows to register new algorithm?

[ziluvatar]

Do you mean your own signing / verification algorithm?

[ziluvatar]

Sorry I just saw your PR #429
I'm not sure about it, in case of adding it, it should not be 'custom' algorithm. As it is mentioned in JWA it should be a qualified name to avoid collisions https://tools.ietf.org/html/rfc7515#page-10.

Maybe using something similar to how passport or oauth2orize library work. Where you could do like (just wondering):
jwt.useAlg('http://mysite.com/blah', signFunction, verifyFunction)

Curiosity, what is the reason behind implementing your own algorithm?

[Teukros]

Of course it can be renamed from "custom" to whatever you prefer. I could also add another option like boolean "customAlgorithm" instead of passing algorithm name. Another solution is also to register a new algorithm right on the beginning when you require the library, but it would need bigger intervention in code and storing global (in scope of lib) object with algorithms used so I don't like it.

The reason why I want to implement my own algorithm is to use the library in every case when I handle request. Sometimes requests need HS256, RS256 encoding, and sometimes it will be our own algorithm (let's name it ABC). Thanks to this change, I can use jsonwebtoken lib in every case, using the same function. If it's ABC alg, I will have to pass additional option with algorithm function, but it's still the same logic.

I tried to find your example with jwt.useAlg in passport & oauth2orize libs, I wasn't able to find them - could you please tell me where is it?

[rochdev]

Not sure if this is the right issue for this, but we have a very similar use case where we want to use an existing algorithm (RS256) but do the signing through an external party (Google Cloud) where we never have the private key.

With the syntax @ziluvatar have mentioned it would work in our case by doing something like this:

jwt.useAlg('RS256', () => iam.projects.serviceAccounts.signBlob(...))

Since only Google can verify the signature in this case the verifyFunction should probably be optional.

[ziluvatar]

I think your case @rochdev is slightly different, 'RS256' is supported by this library, we would need to analyze better that approach.

@Teukros I meant this library https://github.com/jaredhanson/passport
There you have separation between configuration and usage (passport.use() vs passport.authenticate())

So you could have once:

jwt.useAlg('http://mysite.com/blah', signFunction, verifyFunction)

As I said. That would register those callback functions for the new algorithm. From now on the library (jwt) would understand it in any place if you do: jwt.verify(token, { algorithms: ['http://mysite.com/blah']} (similar with sign()).

Since using your own signing algorithm is something risky to do this way seems separated from the sign/verify api itself. Apart from that its usage is more comfortable in the rest of places where you have to use sign/verify api. Other reason is that you have both needed callback + algorithm id in one place.

Let me know what you think.

[ziluvatar]

Giving more thinking into it, another option could be to re-use the algorithm option, so if you pass an object the libraries understand that is a custom algorithm (id + signingFn on signing, id + verifyingFn on verifying). This approach is quite similar to yours, avoiding the creation of another property, and fitting semantically with what we currently have.

[Teukros]

@ziluvatar I thought about using algorithm option for introducing my own function but I wasn't sure if it's a good approach. If we expect that given option is a string, maybe we should stick with that?

I could register callback function for a new algorithm, but it would be a bigger feature and also a bigger change of existing code. What do you think?

[ziluvatar]

If we expect that given option is a string, maybe we should stick with that?

We can stick with it or not, we can decide now :) Semantically it makes sense to me that you could pass "an algorithm" to the algorithm option. So you could pass an algorithm or a algorithm id in the case that algorithm is already built in the library.

[Teukros]

Ok then - I will implement this change soon.

[Teukros]

@ziluvatar I made such change. Now you can put to options.algorithms function directly. You just have to define proper function which will handle correct amount of arguments.

[panva]

#429 (comment) closing this as stale