This section shows how to configure an MPC node to accept various kinds of SDK authentication. See this section for more about how to handle authentication from an SDK user perspective.

API Keys

The configuration file can contain a number of API keys. In the following there are three API keys.

[Authentication]
  
TokenLifetime = "5m"
  
[[Authentication.APIKeys]]
  APIKey = "1PebMT+BBvWvEIrZb/UWIi2/1aCrUvQwjksa0ddA3mA="
  ApplicationID = "app1"
  
[[Authentication.APIKeys]]
    APIKey = "FfrI+hyZAiVosAi53wewS0U1SsXKR0AEHZBM088rOeM="
    ApplicationID = "app1"

[[Authentication.APIKeys]]
    APIKey = "NaseBBHEzG7KqmdqTH/vJZeYeZ7UCtCfsHra6QK9DHo="
    ApplicationID = "app2"

Each APIKey contains the base64 encoded SHA-256 hash of the actual API key. The hash of the API key apikey1 can for example be generated with the following command:

echo -n "apikey1" | openssl dgst -sha256 -binary | openssl base64

When logging in with an API key, the SDK will log in to a specific application in the MPC node. If the application does not exist, it will be created automatically. In the above example, the to first API keys are hashes of apikey1 and apikey2 and they are configured to map to the application app1. The third API key, apikey3 maps to the application app2.

Crypt hashes with the following algorithms are also supported: MD5, SHA256, SHA512, bcrypt, Argon2i, Argon2id. Some examples:

mTLS

The MPC node can also be configured to require SDKs to authenticate using 2-way TLS (mTLS).

[TLSUserAuthentication]
  
  # Points to a file containing a list of CAs from which client certificates are accepted.
  ClientCAFile = ""
  
  # Contains a CSV with the base64 encoded CA certificates from which client certificates are accepted.
  ClientCAList = ""
    
[[TLSUserAuthentication.Applications]]
  
  # These values are used for identifying different applications. The value is an array containing
  # subsets of these values:  "Country", "Organization", "OrganizationalUnit", "Locality", "Province",
  # "StreetAddress", "PostalCode", "SerialNumber", "CommonName", "ExtraNames". If empty or not
  # specified, the distinguished name of the Issuer and Subject from the certificate will be used.
  #  Issuer = ["value0", "value1"]
  #  Subject = ["value0", "value2"]

See this section for more about how to use the SDK with mTLS authentication.

OIDC

When instantiating an SDK for an MPC node in the TSM, you have the option to authenticate using an OIDC access token. To do this, add a section similar to this to the node configuration file:

[OIDCAccessTokenAuthentication]
  
  # List of supported OIDC issuer URLs.
  OIDCIssuers = []

  # Configuration for applications that are allowed to access the TSM
  [[OIDCAccessTokenAuthentication.AccessTokens]]

  # The name of the application to authenticate, must match audience (aud) in access token
  Audience = "application name"

  # The URL of the discovery document for this access token, used to retrieve the public key. 
  # Defaults to issuer + "/.well-known/openid-configuration".
  DiscoveryDocURL = issuer + "/.well-known/openid-configuration"
  
  # The claims which the access token needs to match. If no claims are required, you still need to
  # add an empty section.
  [[OIDCAccessTokenAuthentication.AccessTokens.claims]]
    claim0 = "claim value 0"
  
  [[OIDCAccessTokenAuthentication.AccessTokens.claims]]
    claim1 = "claim value 1"
    claim2 = "claim value 2"

The MPC node(s) will then validate the access token by

• Verifying the signature by getting the public key from the DiscoveryDocURL.
• If the exp-claim has been set, the expiration time will be compared to the current time on the MPC node, and authentication will be rejected if the token has expired. If the nodes and the identity provider are in different timezones, you need to make sure the expiration time is offset accordingly.
• Comparing the claims in the access token to what has been specified in the configuration file for the TSM node

Note that the audience and the application name must match!

📘

CAVEAT

Do not use the same OIDC access token for authenticating towards different TSM nodes. If you use this approach, you risk one node impersonating a user, by sending a received access token to the other nodes.