• Security Configurations
• Protocol
• Security Options
  • Enable CORS on API
  • Enabling CORS on Web
• Signature Verification
• Captcha
• Allowed Urls

#Security Configurations

#Protocol

Specify if the server should enforce HTTPS. This option is enabled by default and recommended.

In some cases, you may require your SSO Server to be provided insecurely through HTTP. For example, when proxying over CloudFlare or your own reverse proxy, and you have no choice but to use flexible connection type. In that situation, you may consider switching to HTTP to suit your requirements on your own risk.

#Security Options

#Enable CORS on API

Enable or Disable CORS (Cross-Origin Resource Sharing) on API call.

Don't enable this unless you are self-assured. This may enable browsers to call SSOfy APIs through the web browser.

#Enabling CORS on Web

Enabling CORS on Web allows for the SSO server to accept requests from other domains, which can be useful in certain scenarios like when embedding the SSO in an IFrame (not recommended).

#Signature Verification

SSOfy uses the "Sign and Verify" technique to secure communications between the api client and server and ensure that the request originated from the authorized source.

Requests to the SSOfy server must contain the Signature attribute in the request headers.

Yet, there are situations when you may need to disable the signature verification, particularly for Test and Debugging purposes.

Make sure to reactivate the verification once you've finished your testing.

#Captcha

Choose the engine that will be used to deliver the captcha security challenge. SSOfy supports both the popular reCaptcha and hCaptcha.

Additionally, SSOfy offers a self-rendered captcha engine dubbed Simple captcha, which generates a classic illustration of a combination of numbers and letters. Some people may find this more clear and familiar for their application.

#Allowed Urls

You can limit the allowed referrer domains provided in the list to increase the security by preventing accesses and redirections which have been coming from unknown domains.

Assume your SSO server is at sso.example.com and you regularly initiate login operations from example.com. website.x impersonates your login button and refers users to sso.example.com. The process should be blocked here since the referrer (website.x) is not trustworthy.