For a lot of reasons, I'm not a huge fan of just going into a package manager and grabbing the first library that comes up on a search relating to a task X. One of the big ones is that I occasionally fear what I will term "suicide by standard." Yes, I get that some group of people has gotten together and decided that insert standard here is a good way of doing things, but what if I don't agree?

...In this case, what I have a problem with is the idea that I should be including a header in a JWT that tells me what algorithm to use to decode it. I know the algorithm, guys; it's my application and I'm the one who made the token. Be reasonable.

I'm also not a huge fan of any of the existing Rust implementations of JWT in that they all seem rather opinionated as to what my payload should be. That doesn't make sense to me, either, so I didn't do that here. Actually, I don't do much at all, and that's pretty easy to see: there were originally only 118 lines of code in this library, and I wanna say 50 of those were dedicated to converting various other libraries' errors into my own.

tl;dr: kitchen sink not included.

• Serializes and signs any payload implementing serde::ser::Serialize
• Deserializes and validates any payload implementing serde::de::Deserialize
• Refuses to waste bits on JWT headers
• Gives no fucks

• Support for serde 1.0. Of course, this means we no longer support anything less than that... This also required some API changes.
• Among other things, that means FromStr on Rwt is now implemented for payloads that also implement FromStr instead of for payloads that directly implement Deserialize.
• Additionally, Rwt(T) now directly implements Serialize and Deserialize for any T which does the same.
• Documentation has been added.
• Lastly, I have reformatted this list and decided that the most recent changes should be at the top.

• In order to avoid a potential timing attack vector, we now use crypto::util::fixed_time_eq to validate token signatures. Props to @Philipp91 for that.

• Rwt struct is now Eq and PartialEq. This is primarily to support testing; whether this has any real purpose for the end user is a mystery to me.

I see very little value in this, personally, but it sounds fun to implement.

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.