Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add JWT bearer authorization #1149
This effort adds the ability for a third-party to sign JWT tokens containing well-formed
The initial version of this PR represents the result of a quick and dirty spike to get something that could be tested against a fast-moving project in the blockchain space. It makes sense to consider this functionality because it allows applications to leverage the existing NATS permissions model without the need for an account server. This is an alternative strategy to nkey auth.
When "bearer authorization mode" is configured, a connection to NATS will fail to be authorized under the following conditions:
The authorization model under this strategy is delegated to NATS by the application, and JWT tokens which an application vends need to be issued with a short ttl; applications and NATS clients need to consider the refresh cycle. I am considering how to best support an interface for defining a configurable callback within NATS clients which will ask the application to vend a new token (i.e. "refresh" the soon-to-expire token) at the appropriate time and gracefully recycle the socket to establish a new NATS connection using the newly-authorized token, just prior to the previously-valid token
There are some obvious things that need to be resolved in the course of diligence here that I am working on:
If you want to run the branch to try it out, you can check it out,
@wuhenfeike if I understand your question correctly, it sounds like it could be supplied within your bearer token similarly to how
That is out of scope for the PR as of this moment but I will take a look to see how it could be supported as I groom this further. It seems you could present those limits as part of the signed token payload as well.
I didn't follow the question related to re-centralizing on a SQL database, you lost me there.
@hastarin this is meant to be very primitive for portability's sake.
The intent of this PR is indeed to allow third-party services to generate and sign JWT credentials (in essence delegating the NATS authorization to some service without having to run extra NATS account server infrastructure). So if the third-party service supports generating JWT tokens with arbitrary claims and signing them using the
Hope this answers your question.