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

Unwrap JWT token #4

Open
omerlh opened this issue Apr 29, 2018 · 7 comments
Open

Unwrap JWT token #4

omerlh opened this issue Apr 29, 2018 · 7 comments

Comments

@omerlh
Copy link
Contributor

omerlh commented Apr 29, 2018

Since Airbag handles all the heavy stuff of validating the signature, it could also pass upstream only the payload of the JWT. Upstream uses only the payload for authorization. This could be done by setting an env var, something like PARSE_TOKEN: true. When this env var is set, Airbag will unwrap the JWT (including base64 decode) and send a header in the following format to upstream:

Authorization: {exp: 234234, iss: blah, should: read etc}

@itaym2 @Yshayy what do you think?

@itaym2
Copy link
Contributor

itaym2 commented Apr 29, 2018

I think a lot of validation libraries expect the jwt to be in it's original form, and using a custom format will force us to write a custom middleware to check it. If we already need to write a custom middleware because we don't validate the signature than it's fine, although it feels weird putting json object in a header (maybe base64 it?)

@omerlh
Copy link
Contributor Author

omerlh commented Apr 29, 2018

As you said we already need to write our custom middleware to check it. I think the whole point of Airbag is making it easier for application to implement authorization, and to simplify testing mechanism. That why I want Airbag to unwrap the token. And that why I don't think we should use base64 encoding - it is just another thing to take care of.

@itaym2
Copy link
Contributor

itaym2 commented Apr 29, 2018

Then maybe another header? something like 'x-token-unwrapped'

@itaym2
Copy link
Contributor

itaym2 commented Apr 29, 2018

or 'x-jwt-payload'

@omerlh
Copy link
Contributor Author

omerlh commented Apr 29, 2018

We can do that, but what's the benefit of that? It's not standard...

@itaym2
Copy link
Contributor

itaym2 commented Apr 29, 2018

that's the point, we are doing a non-standard use of a stand header, so maybe it's better to use a different header.
Not that critical though.

@omerlh
Copy link
Contributor Author

omerlh commented Apr 29, 2018

I tried to loon on alternatives. Looks like both Nginx JWT and Kong JWT also support claims validations, and not passing on the JWT. We can also do this - but it's a lot more complex (for example, one route requires read and another route requires write) because airbag is for the entire server (service mesh might solve this).

I also agree that both options are good enough, I prefer Authorization because it feels more "intuitive" - for example, if we have something that tests for Authorization header. @Yshayy what do you think?

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

No branches or pull requests

2 participants