Crates.io | protobuf-web-token |
lib.rs | protobuf-web-token |
version | 0.4.0 |
source | src |
created_at | 2023-10-28 20:46:40.475296 |
updated_at | 2024-07-15 14:32:02.718509 |
description | Create, verify and decode protobuf web tokens |
homepage | https://github.com/andreasewering/protobuf-web-tokens |
repository | https://github.com/andreasewering/protobuf-web-tokens |
max_upload_size | |
id | 1017182 |
size | 69,391 |
Collection of libraries for different languages to implement signing/verification/decoding of tokens. The approach is similar to the one used in JWT (Json Web Token). The rest of this README assumes that you are familiar what JWTs are used for.
The JSON format is rather inefficient to transfer data with in comparison to a compact binary encoding such as Protocol Buffers. It is in most cases both larger in size and takes longer to encode and decode. However, the advantages of JSON include its human-readability and its typeless nature - the client does not need to know all keys/all value types the server sends in a response. But in a scenario where you have both authorization server and application in your hands this seems like a disadvantage instead: There is a possibility for errors since there is an implicit dependency that will not be caught at compile time.
So assuming we have both authorization server and application in our control we can do "better" (there are still coupling tradeoffs here of course).
We introduce a .proto
file which contains the data we wish to put in the token.
Examples:
The token will also include standardized metadata which right now is just one field:
valid_until
, a unix timestamp of the time where the token should expireWe generate the bindings for the languages using libraries or protoc plugins. For the currently supported languages these are:
Then the authorization server can use the sign
method to sign an object which precisely matches the shape you defined in your .proto
file and the client or other servers can use verify
or decode
to read the contents.
Right now we only support Ed25519. Therefore, the token does not need to include information which verification algorithm needs to be used, which also helps to reduce the size a bit more.