JWT integration with Auth0

[Nick Laqua]

Hi there,

in the context of the OAuth framework, we are considering to use Auth0 as the authorisation server, managing relationships between resource owners (=customers), clients (=internal/3rd party apps) and resource servers. (see https://developer.salesforce.com/page/File:OAuthRoles.png)


Assuming that an API (protected by Kong) can be considered an OAuth resource server, Kong would delegate authentication/authorisation to Auth0. The expectation would be that clients calling an API protected by Kong would include jwt's issued by Auth0, that could be validated by Kong.

According to the Auth0 documentation, Kong (as the API provider) would have to execute the following activities:

1. Parse the JWT to ensure it's well-formed
2. Validate the signature. Assuming the usage of RS256, it could either be done using the JSON Web Key Set provided by Auth0 at a specific URL, or the PEM encoded public key stored in the Kong database
3. Validate the following claims
1. exp.....token not expired yet
2. iss......token has been issued by the right party, in this case my auth0 tenant URL
3. aud.....token audience that the access token is supposed to be used for (unique identifier for API)....for REST API's, this would be equivalent to the API endpoint
4. Check the permissions (i.e. READ, WRITE etc.) via the "scopes" claim....for REST API's, this should be mapped against the HTTP verb (e.g. GET = READ, POST = WRITE, etc.)

From reading the documentation, here is my view of how the existing jwt plugin would cover that

1. Parse the JWT....covered
2. Validate the signature.....I assume, this can be covered by just using a single consumer in Kong where we can store the public key. The creation of the JWT in alignment with the policies would be handled on the Auth0 side
3. Validate claims.....from what I read, only "exp" is covered so far. "iss" and "aud" are not validated at the moment
4. Check permissions ("scope")....not covered

Has anyone played with this and has additional/other comments ?

thanks, Nick

[Thibault Charbonnier]

On 2/20/17 1:01 AM, Nick Laqua wrote:

Hi there,

Hi,

1. Parse the JWT....covered

Correct.

1. Validate the signature.....I assume, this can be covered by just using a single consumer in Kong where we can store the public key. The creation of the JWT in alignment with the policies would be handled on the Auth0 side

Correct.

1. Validate claims.....from what I read, only "exp" is covered so far. "iss" and "aud" are not validated at the moment

Correct. "iss" is by default used by Kong to store the id of the Consumer whose public key should be used to verify the token's signature. It can be changed to another value.

1. Check permissions ("scope")....not covered

Correct. The assumption is that your own service know better how to process the token's claims, or would need to perform additional checks. Kong is also unaware of your upstream services and their responsibilities, as well as your Consumer's roles. Kong will verify the validity of a token itself, as far as the JWT specs goes, but not of its usage inside of your application.

Best,
t.

[Nick Laqua]

Hi Thibault,

thanks for the quick response. My question comes down to two questions

1. How to establish a trusted relationship between the two different OAuth roles "Authorisation server" and "resource server" (assuming that the actual services/resource servers have delegated certain concerns to the API gateway).
2. How to delegate most heavy lifting away from the services to the API gateway

Of course, the overall OAuth model is flexible and can be implemented differently in each architecture, the question is though whether the OAuth support in Kong is flexible enough to support these different scenarios. needless to say, everything has to be compliant with the spec (OAuth and JWT from an authorisation and delegation perspective).

At the end of the day, OAuth 2.0 (and related specs such as OpenID and JWT) have been designed with internet scale and decentralisation in mind.

additional thoughts inline below

Nick

On Tuesday, 21 February 2017 05:29:02 UTC+8, Thibault Charbonnier wrote:

On 2/20/17 1:01 AM, Nick Laqua wrote:

Hi there,

Hi,

1. Parse the JWT....covered

Correct.

1. Validate the signature.....I assume, this can be covered by just using a single consumer in Kong where we can store the public key. The creation of the JWT in alignment with the policies would be handled on the Auth0 side

Correct.

This maps quite nicely to the use case where there is a separate authorisation server which abstracts away the different security use cases/flows, representing the issuer to anyone requiring security services. In the same way that a cert authority issues certificates proving identity claims for organisations. The CA has its own ways of ascertaining the identity and subsequently vouches for these entities by signing the certificate. In this case, auth0 would be the "JA" (JWT authority)

1. Validate claims.....from what I read, only "exp" is covered so far. "iss" and "aud" are not validated at the moment

Correct. "iss" is by default used by Kong to store the id of the Consumer whose public key should be used to verify the token's signature. It can be changed to another value.

Based on the above, there should be a use case where Kong has a trusted relationship with a central authorisation server and only accepts tokens from that one. Could be a configuration setting when applying the plugin on top of an API. But clearly, for our use case of decentralisation, there needs to be some way to establish trust between decentralised parties. Otherwise, anyone can be a CA, and trust establishment would have to be moved to someone else (e.g. the services) which shouldn't have to deal with that.

"aud" is more related to delegating from the services to the API gateway (topic 2 from above). Of course, the spec says that this is application specific and "identifies the recipients that the JWT is intended for" (ultimately the service). But if we chose to standardise that in a way where the audience has to match the endpoint, this could be abstracted away, especially in a REST situation where the endpoint is supposed to uniquely identify the resource (server).

1. Check permissions ("scope")....not covered

Correct. The assumption is that your own service know better how to process the token's claims, or would need to perform additional checks. Kong is also unaware of your upstream services and their responsibilities, as well as your Consumer's roles. Kong will verify the validity of a token itself, as far as the JWT specs goes, but not of its usage inside of your application.

The concept of (access token) scope is quite clearly defined by the OAuth 2.0 spec (section 3.3). It more or less states that the scope granted somehow needs to be communicated between client and authorisation server (e.g. either by granting what the client request or responding with a scope response parameter if the grant is different from the requested scope). In any case, it makes sense to encode the scope into the access token (otherwise, what's the point anyway). Based on that, if there is a clear mapping between swagger/openAPI operations and the way the scopes are defined ("read:customers" --> GET /customers), then this permission check can be delegated to the API gateway.

Best,
t.