rrrodzilla/rusty_paseto

A type-driven, ergonomic RUST implementation of the PASETO protocol for secure stateless tokens.

• 👋 Hi, I’m @rrrodzilla. I live on a sailboat with my family. Most of my code is created off-grid with solar power on the Pacific Ocean.
• 👀 I’m interested in open source software and solutions that make the world a better place.
• 🌱 I’ve been architecting technology solutions, leading software delivery teams and hacking code for over 25 years.
• ☁️ Former Principal @ AWS focused on the Rust programming language and now owner and founder of Govcraft.

I've helped ship a few mainstream products and a bunch of large service delivery platforms for very large governments/telcos/retail/airlines/etc

Some notable projects	Role	Shipped
Microsoft LiveMeeting (breakout rooms feature)	Architect	2004
Turkcell Service Delivery Platform (Turkey)	SOA and Solution Architect	2005
Telstra Service Delivery Platform (Australia)	SOA and Solution Architect	2006
Microsoft Dynamics 2008	Dev lead (SRM component)	2008
Microsoft Azure v1	TAP Architect	2009

• 📫 Hit me up on Twitter or email me at [email protected]

rusty_paseto's Issues

Please update the ring crate to 17.x

This is needed to prevent failures like this.

Add default ExpirationClaim to PasetoTokenBuilder

Default tokens expire in 1 hour. A user can update the expiration time by adding a new Expiration Claim or they can explicitly specify the token should never expire.

Wrong pasteo token cause runtime panic

Describe the bug
While testing i discovered a case where the library will panic instead of throwing an error. Explicitly while attempting a wrong token "v4.local.1234".

The error is

rusty_paseto-0.6.0/src/core/paseto.rs:766:47:
range end index 32 out of range for slice of length 3

To Reproduce
just try to decrypt "v4.local.1234"

Expected behavior
i was expecting to catch the error same as other errors.

Additional context
I think this problem could be solved by checking the length of the third part. I am interested to create a PR for this as first contribution.

Implement Paseto Token Parser

The generic parser handles decrypting the paseto structure (claims, etc) but does not enforce paseto logic such as validating expiration claim and other time related claims. The Paseto Token Parser should wrap the generic parser with the custom paseto logic.

Implement Paseto Token Builder

The generic builder handles building and enforcing paseto structure (claims, etc) but does not enforce paseto logic such as providing a default expiration claim and issue claim while allowing for overrides and non-expiring tokens. The Paseto Token Builder should wrap the generic builder with the custom paseto logic.

Validate ExpirationClaim in PasetoTokenParser

An expiration claim, if provided, should be later than NOW UTC, else fail validation with an err.

Project still active?

There aren't updates, commits or activity in 6 months.
Is the project still active and/or mantained?

Document v2.local public APIs

Need to implement doc comments and tests for the public API for rust docs.

De-dupe claim keys in builder

Claim keys should only appear once in the top-level JSON payload of the builder to prevent the user from accidentally overwriting claim data in a single build session which would cause confusion. Users should groups of duplicate keys in a child struct with a unique claim key to enable that scenario.

Add Default IssuedAtClaim to PasetoTokenBuilder

A default token should have its issued at claim set to NOW. A user can update the claim by adding an IssuedAtClaim while building the token.

Validate NotBeforeClaim in PasetoTokenParser

The NotBeforeClaim, if provided should be greater than NOW UTC, else throw a claim validation error.

v2.Public Basic Encryption

Docs PasetoParser::<V4, Local>

Hello, could you please add additional information to the docs that if token is expired, then PasetoParser::<V4, Local> will throw an error? That would be cool, because I was trying to find a way to verify token itself. It's a good design choice, but that was not mentioned in docs, or I'm simply blind (sorry 😢)

Add closure to claim validation API

Currently, claim validation is a simple check that the claim exists in the decrypted token and the decrypted value matches the provided value. The API needs to be extended to allow the user to provide their own validation closure in order to support more complex validation scenarios.

Beginner question

Hey hey,

really nice implementation and an amazing documentation!

I'm new to rust and my problem might just stem from the fact that I do not know how to archive this the rust-way.

I'm trying to set a subject claim from a non-static reference/dynamic value in a trait implementation.

let token = PasetoBuilder::<V4, Local>::default()
  .set_claim(SubjectClaim::from(&id))
  .build(&key)
  .unwrap();

From what I understand the signature of set_claim required the argument to have a 'static lifetime which will not be possible for a dynamic value (I could be wrong).

How could this be archived?

plans for v3.public

What is your plans re v3.public will you be supporting it? If so do you have an ETA?

Implement v2.public test vectors

Implement all of the test vectors for v2.public

Swap out chronos implementation for time 0.3

Default to using lighter-weight time crate than chrono for the batteries-included API implementation

Implement Non-Expiring Token

The user needs to be able to explicitly specify when a token should NOT have an expiration date when building a claim.

Bump ring for RISCV support

Currently the direct dependency [email protected] cannot be built on platforms like RISC-V.

So would it be possible to bump ring to 0.17+ (briansmith/ring#1627)?
I try to force a update locally, and it seems the compiler happy with new ring (:

Stray eprintln! in `GenericBuilder::set_implicit_assertion`

Describe the bug
Every time set_implicit_assertion on GenericBuilder is used, the assertion is printed to stdout.

To Reproduce

PasetoBuilder::<V4, Local>::default().set_implicit_assertion(ImplicitAssertion::from("example"));

Expected behavior
For a library to not write to stdout.

ed25519-dalek vulnerability

Describe the bug
Found vulnerability when ruining cargo audit.

To Reproduce
Steps to reproduce the behavior:

1. just run cargo audit.

Expected behavior
the vulnerability can be resolved by bumping up the ed25519-dalek crate version.

Screenshots

Desktop (please complete the following information):

• OS: Fedora
• Browser chrome