search

ramosbugs / openidconnect-rs

OpenID Connect Library for Rust
MIT License
404 stars 100 forks source link

feat: Abstract crypto backends #94

Closed ctron closed 1 year ago

ctron commented 1 year ago

This is a draft/preview/idea on how to abstract the crypto backend.

This wouldn't rely on any feature flags, but would allow the user to choose. Which might make sense for a library.

The follows the idea of e.g.: https://github.com/sfackler/rust-postgres/blob/71668b7f460955750bcfa23ffb3efb022915a6d0/postgres/src/lib.rs#L9

With the difference that you need to specify only a type, not an instance. And that there is a default type.

I am not 100% this idea works out, but I wanted to have some feedback before continuing the work.

ctron commented 1 year ago

Currently it is expected that the code will not compile.

sbihel commented 1 year ago

Hi, just jumping in to say that if you want to abstract the crypto backend and make it configurable, it's probably better to use https://crates.io/crates/signature or https://crates.io/crates/signatory.

Sorry for leaving #58 untouched, I've been busy.

ctron commented 1 year ago

Hi, just jumping in to say that if you want to abstract the crypto backend and make it configurable, it's probably better to use https://crates.io/crates/signature or https://crates.io/crates/signatory.

Sorry for leaving #58 untouched, I've been busy.

No worries. We all got lives :grinning: … I wanted to split this up into smaller bits. So, the next step (this one) would be to create an abstraction layer. To confine the use of ring into one module, and allowing for an additional implementation. Of course, it would make sense to use the crates you mentioned.

ramosbugs commented 1 year ago

if we can achieve feature parity (including platform support being a superset of ring's), I'm happy to migrate entirely off of ring and avoid the complexity of an abstraction layer. is there a use case for retaining ring support?

ctron commented 1 year ago

if we can achieve feature parity (including platform support being a superset of ring's), I'm happy to migrate entirely off of ring and avoid the complexity of an abstraction layer. is there a use case for retaining ring support?

Not from my side, I assumed you wanted to keep it. Yes, that might make things a lot easier.

In this case, just close this PR, and I will continue with PRs, slowly kicking out ring, until it is gone.