Provide alternate authentication method for system accounts (different from user authentication method)

Safer Payments v6.8 introduced full OIDC support. In this version, Safer Payments now does the "heavy lifting", communication directly with the IDP to retrieve an ID token containing the user's information. This is a great feature and works with any IDP. 

As a part of operational process, such as backup, Safer Payments needs to be put into a consistent state, in which the data and config are not updated and can be backed up. It's crucial for the system to be in a stable state when the backup is taken, whether files system based copy, or cloud based snapshots of the disk. Any updates to files while the backup is being taken could potentially corrupt the data or config files, rendering the backup unuseable. 

To accomplish a stable backup, one can shutdown the system or utilize an API call to call "setoffline" or "setonline" functions. Shutting down the system is not practical, especially with larger system which require multiple hours to start up. Using the API is the best way to stabilize the system before taking a backup.

The challenge comes with the OIDC authentication method. The ICCM scripts used to "log in" the system account must go through the authentication flow. Some IDP's allow the user credentials to be sent by the script (Okta), allowing the script to programmatically log in and establish a session. This can then be redirected back to Safer Payments to continue with the rest of the authentication flow.

Other IDPs, such as MS ENTRA ID, do not support programmatic login due to security reasons. Having the same authentication method (OIDC) for both users and system accounts is not possible if the IDP does not support programmatic login.

Suggested Solution:
When OIDC is enabled as the authentication method for users, a different authentication method should be allowed for system accounts. Since system accounts cannot always login when OIDC is enabled (depending on the IDP), it would be better to give the option to specify a different authentication method for system accounts.

For example, if OIDC authentication method is enabled for users, then when system accounts are defined, and the IDP does not support programmatic logins, a different authentication method (such as local user accounts) should be available for the system accounts. In this way, users can leverage OIDC to achieve SSO, while system accounts can avoid being blocked by OIDC and continue to authenticate and provide the ability for scripts which support backups, for example, to continue to function.

In summary, the current implementation of OIDC has use cases which do no allow system accounts to login and access APIs programmatically. This prevents OIDC from being used overall, as all use cases (users and system accounts) need to work.