There is no simple answer.  There are a number of choices depending on how you handle users and your security concerns.

First let me point you to the documentation at http://localhost:57774/csp/docbook/DocBook.UI.Page.cls?KEY=GOAUTH

I'll mention two approaches:

1. In the authorization server authentication callback routine, you can setup a property which will later be included in the JWT which acts as the access token.  This property would specify the access rights.  In this case, the JWT must be signed.

2. On the client machine Cache security roles may be associated with the users which control their access rights.  Then ZAUTHENTICATE may be used to log in the appropriate user based on the user associated with the access token.

Their are lots of possible variation here.  I suggest a read of the documentation and some experimentation.  At that point if all is not clear, a call to support to talk through the options in your specific situation would be the next step.

RFC 7523 specifies the use of a JWT both as an authentication mechanism for a client and as a grant type to obtain an access token.  Cache supports the use of a JWT for client authentication in 2017.1.  There are currently no plans to support the JWT grant type for obtaining an access token.  This is a reasonable enhancement request..  I suggest that you make the request through the WRC including more background on your intended use.  Then priority can be set.

If you decide to add this support yourself, you should change OAuth2.REST to send the token endpoint request to your new class instead of OAuth2.Server.Token.  The method in your new class can check for JWT case and process it or otherwise forward to OAuth2.Server.Token:Process.  The OAuth2.Server.Token: CheckJWTAuthorization method has code which might help you learn how to handle JWT.  Of course, the usual caveats apply to this approach.