Hi Prashanth,

Based on the error status, this looks like an invalid SSL certificate on the REST endpoint. The certificate name is "*" but the server name is "". The certificate would need to have "*" to cover that domain. I would try calling the same endpoint in another test client (or even a web browser) to see if it gives you the same certificate error. If so you would have to get in touch with the owner of that API to fix their certificate.

If you're only able to replicate the issue in your Caché instance I would contact InterSystems Support.

As a last resort, you can probably disable checking the server certificate by doing:

set httpRequest.SSLCheckServerIdentity = 0

This is not recommended because it's insecure, but it might be useful as a debugging tool.

Hi Joseph, I agree on using Client Credentials for this use case. As far as I know this is the only OAuth 2.0 grant type that authorizes server-to-server communication without the context of a user agent logging in. You can implement this in InterSystems IRIS by overriding the ValidateClient() method of the OAuth validation class:

One thing to keep in mind is that by default anybody can register a new client with your authorization server by using the dynamic client registration endpoint. So the presence of a valid client isn't enough to authorize the API call. You will need some additional authorization logic.

The SSO system we use for this Developer Community has a "forgot password" implementation. Unfortunately it is down right now, but under normal circumstances  you would be able to try it out here:

It works as follows:

  • The user enters their email address into a form. They are then taken to another form with an input for a token.
  • If the email address exists in the system, they are sent an email with a secure random token to input. Otherwise they are sent an email with instructions on how to register for an account.
  • Once the user inputs the token from their email to the page, they are taken to another form to set their new password.

It's important to avoid user enumeration by not revealing in the UI whether or not a user with the provided username or email address exists in the system. You should also hash the password reset tokens before storing them in a database, give them a short lifetime before they expire, and invalidate the token after it's used once.

I highly recommend OWASP for more resources on how to do this securely:

Pravin has not followed anybody yet.
Global Masters badges: