Re: JWT token validation on reverse proxy


Drasko DRASKOVIC
 

On Tue, Apr 10, 2018 at 2:58 AM, Jihun Ha <jihun.ha@...> wrote:

Greetings,



When I read the document (https://wiki.edgexfoundry.org/download/attachments/329467/18_03_14_ver_EdgeX-simple-jwt-auth-DRAFT.docx?version=1&modificationDate=1521118200000&api=v2) about reverse proxy and auth server, I had a little confiusion for validation JWT token on reverse proxy.

AFAIK, JWT has a capability to validate the received token by resource server without any query to auth server or database, which can be done by self-containing information in JWT token.

So if reverse proxy is employed and API request with JWT token is sent to the reverse proxy, I think it can validate the token by itself without query to Authorization Server.
True - token can be validated, but if we want to support token
revocation, then Auth server must look into the DB and see the list of
revoked tokens, in order to refuse the token which has been revoked.

In it's basic way of usage, JWT do not support/advise revocation -
because it is stateless and has short TTL, thus has to be continuously
refreshed (or re-generated by user re-log). However, in the case of
devices these JWTs should be observed purely as a bearer tokens, a
keys that never expire, so can be eventualy revoked on the server if
key is leaked from device's flash. This makes these JWT stat-full, and
you need a DB to track the list of revoked keys.


But Page 2~3 in the attached document describes that Reverse Proxy receives the JWT token and query the token to Authorization Server, which looks weird to me.
Where you will keep a JWT sercret and verify the JWT - even if it is
stateless - it's up to you. So we can put it in reverse proxy if it
supports JWT check (Kong does, but not every proxy has this
functionality), or you can give this secret to every single service
and let it decode the JWT (only if these JWTs are stateless, as I
mentioned before). I find this less secure, and prefer concentrating
secret to one single dedicated service (Auth server) - and anyway,
device JWTs will probably be state-full, so handling everything on one
Auth server makes sense.

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
Twitter: @draskodraskovic

Join EdgeX-TSC-Security@lists.edgexfoundry.org to automatically receive all group messages.