Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement authenticators based on formats #17
The idea is it to create a modular authenticator system that can be composed of small units, where each has it's simple purpose. The end user should not deal with this modular system for the most common authenticator use cases, but it should be easily possible to create own implementations for custom use cases.
Currently all the implemented authenticators share a lot of the same or similar code. The idea is it to identitfy this code share and extract it in reusable modules that can be shared between authenticator implementations. As next I'll list the identified points:
Currently every authenticator implementation has it's own model which stores the authenticator specific data. Every model implementation consists mostly of the same data. The goal is it to have only one model for all authenticator implementations, supporting all shared features complete and all other features in an optional way. The model can also store custom user data, which was previously only supported for the JWT authenticator.
Three of four authenticators will be serialized into a string format. Two of them use a custom serialization format and one will be serialized as JWT. The idea is it to use only one serialization format for all three authenticators. It makes most sense to choose JWT as serialization format because it comes with the JWS(JSON Web Signature) standard and the JWE (JSON Web Encryption) standard built-in. There was recently a post about JWT on HN which criticized the JWT format and JWE in general. The JWE criticism comes from the fact that there are to many used encryption algorithms where each has its own security issues and from the fact that cryptographers should choose the right algorithms and not developers. As a better alternative for encryption we could use Libsodium as suggested in the post. All other criticized issues can be fixed by choosing the right JWT library and by verifying the signature algorithm. The new design makes it also possible to change or implement a new serialization/deserialization format easily. But for the first implementation we drop our custom format and switch to JWT.
Currently validation is implemented in different ways. The models itself implement validation for the time based functionality. Some services implement also validation for the fingerprint value. Validation is currently not extendable. So the goal is it to provide validators which operates directly on the authenticator model. In custom cases the user can define which validators should be applied to the model.
Every authenticator reads data from the request and writes data to the response. This API should be unified to make it shareable between authenticator use cases. It should be possible to read different authenticator formats from different transports (JWT from Cookie, Bearer from Header, ...) for a single endpoint, so that users can handle different types of clients with a single backend without duplicating endpoints.
Authenticators are typically stored in the request. But it can also make sense to retrieve authenticators from other sources like actors as example. This means that the authentication API should not be tied to a HTTP request. It should be possible to use other sources as well.