Kong: [OAuth2-plugin] JWT Token

[codebien]

It would be very useful if the OAuth2 plugin provided the ability to issue JWT tokens instead of reference tokens. This would improve performance as it would avoid the need to peform queries when verifying a token.
Moreover, it would be even more useful if the plugin allowed to configure custom fields (and related values) to insert in JWT tokens for each Oauth2 application (for example by providing a "JWT" field when creating an Oauth2 application). All the custom info should then be forwarded to API insances.

[ambrons]

@codebien Do you mean in place of using the X-Headers that are attached to the request to services upstream of the kong proxy? That was my same consideration as well.

[ambrons]

So I've posted a lot of my thoughts about why I think adding JWT support would be great for the tokens in #1023 , however I'll summarize here.

So to elaborate on JWT. My personal taste would be to use JWT over the following headers supplied to my microservice in it's current implementation. It concerns me that the microservice's user identity is contingent on the trust of the mutable headers added by Kong.

So the headers added by Kong for the upstream API are:

X-Consumer-ID, the ID of the Consumer on Kong
X-Consumer-Custom-ID, the custom_id of the Consumer (if set)
X-Consumer-Username, the username of the Consumer (if set)
X-Authenticated-Scope, the comma-separated list of scopes that the end user has authenticated (if available)
X-Authenticated-Userid, the logged-in user ID who has granted permission to the client
Contrast that with a (JWT)[http://jwt.io/], which is signed and therefore immutable. You can guarantee that from the time the access_token was verified to the time the upstream service received the request that was zero tampering to the identity information.

The idea would be for the existing access_token as a _by reference_ token, and instead of the added X- headers convert that into a _by value_ token, IMHO a JWT. Obviously this probably needs to be configurable.

We've already built some of this as an external server, but since the introduction of Kong it would be nice to move that functionality into Kong as well.

Here's the architectual concept laid out in (How To Control User Identity Within Microservices)[http://nordicapis.com/how-to-control-user-identity-within-microservices/]

@thefosk I would love to get your thoughts on this. If it's heading in a direction you'd agree with I don't mind putting together a PR.

[codebien]

@ambros IMO we are talking of two slightly different questions
What I requested is to have kong issuing (customizable) JWT instead of reference tokens.
Then, how the information carried by the JWT is forwarded to upstream services is, IMO, of secondary importance.

What you are saying is, according to my understanding, to group the various X-Header (that are currently proxied to upstream services) in a JWT, is it correct? Then this is another issue.

IMO this issue has 3 different points to discuss:

1. Capability to issue JWT tokens instead of Reference tokens when an
   API's user hit /ouath2/token.
2. Capability to insert custom fields into JWT tokens. They could de defined when an OAuthApplication is added, like this:

json { "name": "test", "client_id": "SOME-CLIENT-ID", "client_secret": "SOME-CLIENT-SECRET", "redirect_uri": "http://some-domain/endpoint/", "jwt": { "myCustomField1": "user role", "myCustomField2": "user age" } }

1. How to proxy the information carried by the JWT to upstream services. IMO, there are 3 possible ways:
   
   
   
   • Proxying the whole JWT as it is received after verification
   
   
   • Proxying only a JSON that contains the custom fields as a string in an X-Header
   
   
   • Proxying each custom field in a dedicated X-Header
   
   

[ambrons]

@codebien I agree we're talking about JWT but at different sides of Kong. I believe adding support for JWT in generate for the token of oauth2 is a plus.

What you are saying is, according to my understanding, to group the various X-Header (that are currently proxied to upstream services) in a JWT, is it correct? Then this is another issue.

Yes I'm advocating using a Value JWT in place of the oauth identity X-Headers as it's immutable once signed.

On your 3 points:

1. Capability to issue JWT tokens instead of Reference tokens when an
   API's user hit /ouath2/token.
   I agree 100% on additiong JWT tokens as an option for access tokens when making requests to /oauth2/token.
   Capability to insert custom fields into JWT tokens. They could de defined when an OAuthApplication is added
   I think this would be nice to have and I would certainly like this information on the upstream service side. I'm assuming you means these would be derived? Derived from what?

Also because JWT are only signed, not encrypted it's strongly cautioned against putting much information in the claims section. So this is why I made reference to a "by reference token" that looks like this on the public side with a payload like this:

{
    "iat": 11111111,
    "exp": 2222222,
    "iss": "abcd1234dcba4321",
    "sub": "54321abcdf12345fdcba"
}

Where iss would be configured in Kong to represent Kong's identity as the issuer of the JWT. The sub would be an opaque identifier that could be used by the frontend to make additional requests to other services to get more information about an identity.

3.How to proxy the information carried by the JWT to upstream services. IMO, there are 3 possible ways:

• Proxying the whole JWT as it is received after verification
• Proxying only a JSON that contains the custom fields as a string in an X-Header
• Proxying each custom field in a dedicated X-Header

So this is the part I carried more about then the front end, mainly because I believe in opaque tokens or "reference" tokens on the front-end. So the way things are today I'm okay with. Obviously this is where we differ in opinion and features.

So on the back-end the Authorization header would set with a JWT "by value" token which would include all the existing X-header information today:

X-Consumer-ID
X-Consumer-Custom-ID
X-Consumer-Username
X-Authenticated-Scope
X-Authenticated-Userid

But in addition could contain information such as you suggested coarse grain role information probably out of the consumer database or a 3rd party store. Basically enough information such that the microservices on the back-end don't need to lookup additional information to do anything.

All of that being said I believe that this should be configurable by the user of the plugin. So if they wish to use the traditional opaque bearer tokens and X-Headers they can.

[t1tcrucible]

@ambrons We have developed a JWT plugin that generates a JWT (including Kong X-headers) for upstream API.
The JWT requires:

• an authentication plugin to be enabled on the API
• JWT credentials to be provided for the requesting consumer

I can make a PR to Kong, but I don't know if this is usefull for core.
The reason we have developed this plugin for an existing customer that want to standardize upstream info coming from Kong for all APIs as mentioned in your refering article.

The plugin can be used from Kong 8, and re-uses the jwt_parser lua file from the jwt plugin.

[t1tcrucible]

comments are welcome:
https://luarocks.org/modules/trust1team/kong-plugin-jwt-up

[ambrons]

@t1tcrucible Thanks for the update. I actually went another direction do to the eco system we're already running it we found alternatives. That being said I'd be interested in looking at the plugin and providing feedback.

[t1tcrucible]

Our goal is to implement other authentication protocols, all resolving in signed JWT token (now HS256, but will go to RS256) for upstream.
Anyway, I'll PR to Kong - to see if it can be reviewed/commented.

Still have some tests to add.

[michallis]

Some additional information, for a customer we had the following issue:

• an API is protected with JWT policy, and in need of a end-user token (the user has to perform a login, and a generated token is issued upon successful login).
• the end-user can be authenticated towards the API, and the upstream server obtains the end-user context.
• the application consumer, runs some background jobs, targeting the API aswell, but can authenticate using key-auth.
• in any case (key-auth by application consumer, JWT for end-user requests) a JWT should be available for the upstream API (in our case signed with a certificate, thus RS256).

Problems we have:

• combination key-auth + JWT demands both

We update the JWT-up plugin to always deliver a JWT for any authentication performed. This can be really particular, and maybe discouraged from a security perspective.

For example:

• application consumer + key-auth => jwt credentials for app consumer are used in the plugin to generate on the fly a JWT before proxying to upstream + all Kong headers are transformed to claims
• end-user + JWT => perfoms the same checks as the JWT policy + adds all Kong headers as claims to the JWT (and implicitly generates new JWT) before sending upstream

We don't have performance impact yet. But would be happy to have some feedback about the approach.

[kkrol89]

Does anyone have update about this issue?
@t1tcrucible do you still use your solution? Are you planning to merge it into kong repo?