Renamed to anmolitor/protobuf-web-tokens. It is published under that name, and new versions come out there.
Versions published as andreasewering/protobuf-web-tokens still install under that name. 2 versions of 3 come from the new location (see their notes).
Rerouted (renamed, needs approval). The GitHub user or repository was renamed. The tag is still there, at the new name. The Lamdera package server serves a copy recovered from https://github.com/anmolitor/protobuf-web-tokens.
What we checked: The repo moved to github.com/anmolitor/protobuf-web-tokens and tag 1.0.0 is there; its commit da2ed2ff4eff is from 2023-12-19 12:27 UTC, after the version was published (2023-10-29 10:40 UTC); elm.json differs from package.elm-lang.org's; the exposed modules match docs.json; the zip's SHA-1 is not the published one and nothing else confirms its contents.
We could not verify this copy against what was published, so the Lamdera compiler asks before using it (y/n). Without a terminal, as in CI, it stops with an error unless approved:
lamdera make --auto-approve-package-rerouting approves rerouted versions for that run,LAMDERA_AUTO_APPROVE_PACKAGE_REROUTING=1 does the same for every run in that environment,LAMDERA_CACHE=off skips the Lamdera package server altogether: packages come from package.elm-lang.org and GitHub only, as with elm, and a rerouted version then fails to download.Details · package.elm-lang.org's zip: https://github.com/andreasewering/protobuf-web-tokens/zipball/1.0.0/
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.