oxide-auth
oxide-auth copied to clipboard
HeroicKatora
JWT and JWE compatible Self-Encoded Access Tokens
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
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...
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)?
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.
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?
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.
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
jsonbody 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 ^^')
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.
