An observation from trying JWT on my REST endpoints that were tripping me up -- I previously had UseSession enabled and that appears to conflict with CSP and JWT handling. I understand that disabled is its default setting, but if it's enabled, well, you waste a bit of time wanting an access token.

Please consider returning the error code as shown below for when you are NOT providing a delegated set of credentials. We use this to allow for "break the glass" access by an authorized Systems Administrator using sudo irisdb without having them required to enter another password:
 

GetCredentials(ServiceName,Namespace,Username,Password,Credentials) Public {

 s $zt="Error"

 // The following example sets the processes Username/Password without prompting them
 // to _SYSTEM/SYS if a console,and Admin/SYS if a telnet user.
 // If a Bindings service, then we will go through the normal login screen.

 ; i ServiceName="%Service_Console" {
 ;      s Username="_SYSTEM"
 ;      s Password="SYS"
 ;      q $SYSTEM.Status.OK()
 ; }

    ;do ##class(%SYS.System).WriteToConsoleLog("GetCredentials("_$g(ServiceName)_","_$g(Namespace)_","_$g(Username)_","_$g(Password)_","_$g(Credentials)_")",0,0)
    if (ServiceName = "%Service_Terminal") && ($username = "root") {
        set Username = "root"
        set Password = "should match whatever is set for local user"
        quit $SYSTEM.Status.OK()
    }

 // For Bindings applications, force them to normally enter a username
 ; i ServiceName="%Service_Bindings" q $SYSTEM.Status.Error($$$GetCredentialsFailed)
 // If a CSP application, we can test for a specific application by looking at
 // the request object. If it exists, then the request is from a CSP application.

 ;If $isobject($get(%request)) {
 ;  if %request.Application="/csp/samples/" {
 ;      set Username="_SYSTEM"
 ;      set Password="SYS"
 ;      quit $System.Status.OK()
 ;  }
 ;}

 // Here is an example where I get the username and password out of a http request where the password
 // was set the following way:
 // d httpreq.InsertParam("username","TESTDEL")
 // d httpreq.InsertParam("password","SYS")
 ;If $isobject($get(%request)) {
 ;  if %request.Application="/csp/samples/" {
 ;      s Username=$get(%request.Data("username",1))
 ;      s Password=$get(%request.Data("password",1))
 ;      quit $System.Status.OK()
 ;  }
 ;}

 // For any other service, deny them access
 ;q $SYSTEM.Status.Error($$$AccessDenied)

 // By default, we allow the system to do its normal Username/Password prompting.
 q $SYSTEM.Status.Error(1419 /*$$$GetCredentialsFailed*/)

Error //Handle any COS errors here
 //Reset error trap to avoid infinite loop
 s $zt=""

 //Return the generalized COS error message #5002
 q $SYSTEM.Status.Error(5002 /*$$$CacheError*/,$ze)

}

I won't repeat the excellent definitions already provided, but can share some examples of class parameters where we use them:

Parameter FILES = "/files";
Parameter INSTANCE As COSEXPRESSION = "$p($SYSTEM, "":"", 2)";
Parameter RUNLEVEL As COSEXPRESSION = "$li($lb(""dev"",""Test"",""LIVE""), $lf($lb(""HCDEV"",""HCTEST"",""HCLIVE""), ..#INSTANCE))";

We use ..#FILES to prefix or normalize a directory off the top-level filesystem on the server.

We use ..#INSTANCE if we need to identify which IRIS instance, like in an email message, it came from.

We use ..#RUNLEVEL in conditionals or pass as a parameter, where we might want code only to run on "Test" or "LIVE".