Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JWT and JWE compatible Self-Encoded Access Tokens #7

Open
1 task
HeroicKatora opened this issue Feb 6, 2018 · 8 comments
Open
1 task

JWT and JWE compatible Self-Encoded Access Tokens #7

HeroicKatora opened this issue Feb 6, 2018 · 8 comments
Labels
feature Unimplemented addition

Comments

@HeroicKatora
Copy link
Owner

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 HeroicKatora modified the milestones: 0.2, 0.3 Feb 6, 2018
@HeroicKatora HeroicKatora added the improvement Improve existing implementation label Feb 6, 2018
@HeroicKatora HeroicKatora added feature Unimplemented addition and removed improvement Improve existing implementation labels Feb 23, 2018
@HeroicKatora
Copy link
Owner Author

HeroicKatora commented Apr 19, 2018

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 HeroicKatora removed this from the 0.4 milestone Jan 20, 2019
@Geobert
Copy link
Contributor

Geobert commented Apr 28, 2020

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
Copy link
Owner Author

HeroicKatora commented Apr 28, 2020

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
Copy link
Contributor

Geobert commented Apr 28, 2020

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
Copy link
Owner Author

HeroicKatora commented Apr 28, 2020

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
Copy link
Contributor

Geobert commented Apr 28, 2020

Thank you very much!

@Geobert
Copy link
Contributor

Geobert commented Apr 28, 2020

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Unimplemented addition
Projects
None yet
Development

No branches or pull requests

3 participants