Provide ability to create a API-Key records in names.nsf for third party applications to connect to Domino resources for various reasons (Mostly REST-API, Web agents, DAS, etc.)
Right now customers provide a separate username password and the other parties use basic authentication. However this quickly escalates to a security nightmare after a point, especially when the company provides access for too many different parties. In addition, every user account with a static password is a security risk. Password management policies, e-mail routing and similar admin practices complicate management of these accounts further.
The idea is to create an alternative account type named API access.
- The credential may be formed in a long, random and complicated single string that is difficult to guess.
- Every API access account will have a separate name, so they can be referred in the Notes security model (ACL, reader/author, etc).
- API key will be valid only for specified URL patterns (that will also be automatically excluded from TOTP and Session authentication)
- API key would be defined for permanent access or it might expire after a limited time.
- Just like standard names.nsf documents, API keys should have Administrator user so they can generate new keys without admin involved.
I’m guessing if you put an OIDC provider connected with Domino that will work.
But it would be better if Domino could create these JWT tokens by it self using a notesid file in the id vault.
Would this OIDC Bearer token authentication that was introduced in V12.0.2 be the solution you were looking for ?
I support this idea.
API keys appear to be the natural choice, when software components should consume Domino based services (machine-to-machine communication).
E.g. Volt Apps could become more attractive as machine-consumable services.
The alternative, x509 Client Certificates, are not working in situations when L7 Load Balancing has to be used.