As Alexander said, the Creating the Server Configuration Items Programmatically link should have the information you need. Note, in particular, the types of the properties. Looking at what you have here, the IssuerEndpoint and SupportedScopes properties are of the wrong type: IssuerEndpoint needs to be an OAuth2.Endpoint object and SupportedScopes is an array of strings so should be set withdo oauth2server.SupportedScopes.SetAt(<scope description>,"ikp-scope")
Hi M C,
Currently, you cannot add custom headers to a JWT. On top of this, the x5t header parameter (which, as I'm sure you're aware, is required for Microsoft Identity platform JWT assertions) is not added to JWTs in ObjectToJWT(). Unfortunately, this means that 2 of the 3 options Microsoft gives for the client credentials flow will not work. If you need the client credentials flow and can use the first case in that Microsoft page you linked to (access token request with a shared secret), that's probably your best bet.
(Also, to circle back to your original question, while you do not need to set your production up as an OAuth client to use JWTToObject() and ObjectToJWT(), you should do so in this case because you are using it as an OAuth client.)
Sorry to be the bearer of bad news, but I hope this helps,
McLean
There's a $SYSTEM.Encryption.RSAGetLastError() function that might provide more insight into why validation is failing in this specific case. The code snippet seems correct, so my guess is that this is not the reason validation is failing. Could the signature have been made over more than just the string "hello"? Could the cert have a public key that doesn't correspond to the private key used to make the signature?
It shouldn't be the case, but does it work if you have set isValid = $SYSTEM.Encryption.RSASHAVerify(256, tData, tSignature, tX509.Certificate,"","")? (Because the method does take 6 arguments, though the last two should be optional)