oxide-auth icon indicating copy to clipboard operation
oxide-auth copied to clipboard

JWT and JWE compatible Self-Encoded Access Tokens

Open HeroicKatora opened this issue 6 years ago • 8 comments

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

  • [ ] A pull request does not yet exist

HeroicKatora avatar Feb 06 '18 18:02 HeroicKatora

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...

HeroicKatora avatar Apr 19 '18 19:04 HeroicKatora

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)?

Geobert avatar Apr 28 '20 15:04 Geobert

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.

HeroicKatora avatar Apr 28 '20 16:04 HeroicKatora

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?

Geobert avatar Apr 28 '20 16:04 Geobert

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.

HeroicKatora avatar Apr 28 '20 16:04 HeroicKatora

Thank you very much!

Geobert avatar Apr 28 '20 16:04 Geobert

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 ^^')

Geobert avatar Apr 28 '20 16:04 Geobert

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.

Bessonov avatar Jan 29 '22 20:01 Bessonov