HeroicKatora / oxide-auth

A OAuth2 server library, for use in combination with actix or other frontends, featuring a set of configurable and pluggable backends.
655 stars 88 forks source link

JWT and JWE compatible Self-Encoded Access Tokens #7

Open HeroicKatora opened 6 years ago

HeroicKatora commented 6 years ago

Feature

To ensure compatibility and transparency, the self encoded access tokens should be structured based on an open standard, such as JWT. Since private data is needed for several potential extensions, encryption with JWE should also be possible.

This should ultimately lead to better interoperability with clients and might improve debugging as supporting tools etc. are developed independently.

Tracking pull request

HeroicKatora commented 6 years ago

Since JWT is suboptimal from many security standpoints, I might consider supporting Paseto instead.

Other considerations involve macaroons.

Informal comment: Supporting a standard that does mac then encrypt while still requiring/offering support for PKCS #1v1.5 just feels very wrong for a library that has essentially been started in 2018...

Geobert commented 4 years ago

Oh, I was looking around on how to generate a (signed) JWT token and stumble on this ticket.

So if I understand properly, it's not possible at the moment (0.5-preview-0)?

HeroicKatora commented 4 years ago

You can do this with your own Issuer implementation but I probably won't support it in the main crate, and it isn't at the moment.

Geobert commented 4 years ago

Thank you for your answer!

It what I though doing, but the trait Issuer uses IssuedToken and RefreshedToken so I can't add fields to it.

Or I'm misunderstanding?

EDIT: Or maybe just put the JWT token in its String representation in the token field?

HeroicKatora commented 4 years ago

EDIT: Or maybe just put the JWT token in its String representation in the token field?

Precisely. It needs to be a string representation since that is what the OAuth standard requires for the json body of the HTTP response.

Geobert commented 4 years ago

Thank you very much!

Geobert commented 4 years ago

EDIT: Or maybe just put the JWT token in its String representation in the token field?

Precisely. It needs to be a string representation since that is what the OAuth standard requires for the json body of the HTTP response.

Oh sorry to bother you again: I'm learning about TokenSigner and I see that the refresh method is returning Err(()). But there's the option to activate refresh token. Is that an oversight (unlikely) or me not understanding something (more likely ^^')

Bessonov commented 2 years ago

Since JWT is suboptimal from many security standpoints, I might consider supporting Paseto instead.

TBH I didn't read the article carefully, but a blog post from a security firm to put own implementation and consulting forward doesn't feel unbiased. The whole critic is about "too many choices, which devs shouldn't make" and one mistake in the spec, which is trivial to avoid. But wording tells "end of the world, we will all die because of JOSE" and then invent something proprietary (in sense hold by one commercial company) what splits the community. I think JWT etc. still great and should be supported.

Probably, the one critic about post-quantum cryptography is valid. I don't know the whole spec, but it feels like everything is in place and could be added just by adding new algos.