A type-driven, ergonomic implementation of the PASETO protocol for secure stateless tokens.
Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards.
| APIs, Tests & Documentation | v1.
local| v1.
public | v2.
local | v2.
public |v3.
local | v3.
public | v4.
local | v4.
public |
| ------------: | :-----------: | :----------: |:-----------: |:-----------: |:-----------: |:-----------: |:-----------: |:-----------: |
| PASETO Token Builder | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| PASETO Token Parser | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| Flexible Claim Validation | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| Generic Token Builder | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| Generic Token Parser | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| Encryption/Signing | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| Decryption/Verification | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| PASETO Test vectors | [x] | [x] | [x] | [x] | [x] | [ ] | [x] | [x] |
| Documentation | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
| Feature | Status |
| ------------: | :-----------: |
| Feature gates | [x] |
| PASERK support | [ ] |
# Usage rustypaseto is meant to be flexible and configurable for your specific use case. Whether you want to get started quickly with sensible defaults, create your own version of rustypaseto in order to customize your own defaults and functionality or just want to use the core PASETO crypto features, the crate is heavily feature gated to allow for your needs.
## Architecture
The rustypaseto crate architecture is composed of three layers (batteriesincluded, generic and core) which can be further refined by the PASETO version(s) and purpose(s) required for your needs. All layers use a common crypto core which includes various cipher crates depending on the version and purpose you choose. The crate is heavily featured gated to allow you to use only the versions and purposes you need for your app which minimizes download compile times for using rusty_paseto. A description of each architectural layer, their uses and limitations and how to minimize your required dependencies based on your required PASETO version and purpose follows:
batteries_included --> generic --> core
### default The default feature is the quickest way to get started using rusty_paseto.
The default feature includes the outermost architectural layer called batteries_included (described below) as well as the two latest PASETO versions (V3 - NIST MODERN, V4 - SODIUM MODERN) and the Public (Asymmetric) and Local (Symmetric) purposed key types for each of these versions. That should be four specific version and purpose combinations however at the time of this writing I have yet to implement the V3 - Public combination, so there are 3 in the default feature. Additionally, this feature includes JWT style claims and business rules for your PASETO token (default, but customizable expiration, issued at, not-before times, etc as described in the usage documentation and examples further below).
```toml ## Includes V3 (local) and V4 (local, public) versions, purposes and ciphers.
rustypaseto = "latest"
// at the top of your source file
use rustypaseto::prelude::*;
```
### batteries_included
The outermost architectural layer is called batteries_included. This is what most people will need. This feature includes JWT style claims and business rules for your PASETO token (default, but customizable expiration, issued at, not-before times, etc as described in the usage documentation and examples below).
You must specify a version and purpose with this feature in order to reduce the size of your dependencies like in the following Cargo.toml entry which only includes the V4 - Local types with batteries_included functionality:
```toml ## Includes only v4 modern sodium cipher crypto core and local (symmetric) ## key types with all claims and default business rules.
rustypaseto = {version = "latest", features = ["batteriesincluded", "v4local"] }
```
#### Feature gates Valid version/purpose feature combinations are as follows: - "v1local" (NIST Original Symmetric Encryption) - "v2local" (Sodium Original Symmetric Encryption) - "v3local" (NIST Modern Symmetric Encryption) - "v4local" (Sodium Modern Symmetric Encryption) - "v1public" (NIST Original Asymmetric Authentication) - "v2public" (Sodium Original Asymmetric Authentication) - "v3_public" (NIST Modern Asymmetric Authentication) - NOT YET IMPLEMENTED - "v4_public" (Sodium Modern Asymmetric Authentication)
// at the top of your source file
use rusty_paseto::prelude::*;
### generic
The generic architectural and feature layer allows you to create your own custom version of the batteries_included layer by following the same pattern I've used in the source code to create your own custom builder and parser. This is probably not what you need as it is for advanced usage. The feature includes a generic builder and parser along with claims for you to extend.
It includes all the PASETO and custom claims but allows you to create different default claims in your custom builder and parser or use a different time crate or make up your own default business rules. As with the batteriesincluded layer, parsed tokens get returned as a serderjson Value. Again, specify the version and purpose to include in the crypto core:
```toml ## Includes only v4 modern sodium cipher crypto core and local (symmetric) ## key types with all claims and default business rules.
rustypaseto = {version = "latest", features = ["generic", "v4local"] }
// at the top of your source file
use rusty_paseto::generic::*;
```
### core
The core architectural layer is the most basic PASETO implementation as it accepts a Payload, optional Footer and (if v3 or v4) an optional Implicit Assertion along with the appropriate key to encrypt/sign and decrypt/verify basic strings.
There are no default claims or included claim structures, business rules or anything other than basic PASETO crypto functions. Serde crates are not included in this feature so it is extremely lightweight. You can use this when you don't need JWT-esque functionality but still want to leverage the safe cipher combinations and algorithm lucidity afforded by the PASETO specification.
```toml ## Includes only v4 modern sodium cipher crypto core and local (symmetric) ## key types with NO claims, defaults or validation, just basic PASETO ## encrypt/signing and decrypt/verification.
rustypaseto = {version = "latest", features = ["core", "v4local"] } ```
# Examples
## Building and parsing tokens with batteries_included
Here's a basic, default token: ```rust use rusty_paseto::prelude::*;
// create a key specifying the PASETO version and purpose
let key = PasetoSymmetricKey::
```
## A default token
Contains a NotBeforeClaim defaulting to the current utc time the token was created
You can parse and validate an existing token with the following:
```rust
let key = PasetoSymmetricKey::
//the ExpirationClaim assert!(jsonvalue["exp"].isstring()); //the IssuedAtClaim assert!(jsonvalue["iat"].isstring());
```
Validates the token structure and decryptes the payload or verifies the signature of the content
Validates the implicit assertion if one was provided (for V3 or V4 versioned tokens only)
PASETO tokens can have an optional footer. In rustypaseto we have strict types for most things.
So we can extend the previous example to add a footer to the token by using code like the
following:
```rust
use rustypaseto::prelude::*;
let key = PasetoSymmetricKey::
// token is now a String in the form: "v4.local.encoded-payload.footer"
And parse it by passing in the same expected footer
rust
// now we can parse and validate the token with a parser that returns a serdejson::Value
let jsonvalue = PasetoParser::
//the ExpirationClaim assert!(jsonvalue["exp"].isstring()); //the IssuedAtClaim assert!(jsonvalue["iat"].isstring());
```
Version 3 (V3) and Version 4 (V4) PASETO tokens can have an optional implicit assertion.
So we can extend the previous example to add an implicit assertion to the token by using code like the
following:
```rust
use rustypaseto::prelude::*;
let key = PasetoSymmetricKey::
// token is now a String in the form: "v4.local.encoded-payload.footer"
And parse it by passing in the same expected implicit assertion at parse time
rust
// now we can parse and validate the token with a parser that returns a serdejson::Value
let jsonvalue = PasetoParser::
```
As mentioned, default tokens expire 1 hour from creation time. You can set your own expiration time by adding an ExpirationClaim which takes an ISO 8601 (Rfc3339) compliant datetime string.
```rust
use rusty_paseto::prelude::*;
// must include
use std::convert::TryFrom;
let key = PasetoSymmetricKey::
let token = PasetoBuilder::
// token is a String in the form: "v4.local.encoded-payload.footer"
```
A 1 hour ExpirationClaim is set by default because the use case for non-expiring tokens in the world of security tokens is fairly limited. Omitting an expiration claim or forgetting to require one when processing them is almost certainly an oversight rather than a deliberate choice.
When it is a deliberate choice, you have the opportunity to deliberately remove this claim from the Builder.
The method call required to do so ensures readers of the code understand the implicit risk.
```rust
let token = PasetoBuilder::
```
The PASETO specification includes seven reserved claims which you can set with their explicit types: ```rust // real-world example using the time crate to prevent the token from being used before 2 // minutes from now let in2minutes = (time::OffsetDateTime::now_utc() + time::Duration::minutes(2)).format(&Rfc3339)?;
let token = PasetoBuilder::
```
The CustomClaim struct takes a tuple in the form of (key: String, value: T)
where T is any
serializable type
```rust
let token = PasetoBuilder::
This throws an error:
rust
// "exp" is a reserved PASETO claim key, you should use the ExpirationClaim type
let token = PasetoBuilder::
```
rusty_paseto allows for flexible claim validation at parse time
Let's see how we can check particular claims exist with expected values.
```rust
// use a default token builder with the same PASETO version and purpose
let token = PasetoBuilder::
PasetoParser::
// no need for the assertions below since the check_claim methods // above accomplish the same but at parse time!
//asserteq!(jsonvalue["sub"], "Get schwifty"); //asserteq!(jsonvalue["Contestant"], "Earth"); //asserteq!(jsonvalue["Universe"], 137); ```
What if we have more complex validation requirements? You can pass in a reference to a closure which receives the key and value of the claim you want to validate so you can implement any validation logic you choose.
Let's see how we can validate our tokens only contain universe values with prime numbers:
```rust
// use a default token builder with the same PASETO version and purpose
let token = PasetoBuilder::
PasetoParser::
```
This token will fail to parse with the validation code above:
```rust
// 136 is not a prime number
let token = PasetoBuilder::
```
If the API of this crate doesn't suit your tastes, check out the other PASETO implementations in the Rust ecosystem which inspired rusty_paseto:
paseto - by Cynthia Coan
File an issue or hit me up on Twitter!