Resolving Common Issues

On this page, please find the list of common issues, misconfigurations, and their resolution to help you get up and running quickly.

Affinidi Login

Invalid Client (unknown client - Client ID)

The error usually happens after the user clicks on the Login button and receives the following error:

Invalid Client Credentials
Resolution

Please check your Client ID value to see if it is correct based on the Login Configuration you have created.

Invalid Client (unknown client - Client Secret)

The error usually happens after the user clicks on Allow access on the consent page, and your application’s callback endpoint receives the following error:

invalid_client (Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method).)

Resolution

Please check your configured Client Secret to see if it is correct based on the Login Configuration you have created.

Invalid Client (unsupported authentication method)

The error happens after the user clicks Allow access on the consent page. If your application does not support the authentication method configured on your Login Configuration. In that case, your callback endpoint receives the following error:

invalid_client (Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method).)

Resolution

Please check with your application or library which authentication method is supported. Currently, Affinidi login supports the following method:

  • client_secret_basic
  • client_secret_post
  • none

If you implement a Proof Key for Code Exchange (PKCE), set the tokenEndpointAuthMethod to none. You can do this using the Affinidi CLI command:

affinidi login update-config --id <LOGIN_CONFIG_ID> --token-endpoint-auth-method none

Invalid Request (redirect_uri parameter)

The error usually happens after the user clicks on the Login button and receives the following error:

Invalid Redirect URI

The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. The 'redirect_uri' parameter does not match any of the OAuth 2.0 Client's pre-registered redirect urls.

Resolution

Please check if the Redirect URI configured on Login Configuration matches exactly the Redirect URI sent from your application.

Could not send authorization response

The error happens after the user clicks Allow access on the consent page. This issue occurs if your ID Token Mapping has a field conflict where you are mapping a field in ID Token Mapping defined multiple times in the Presentation Definition.

ID Token Mapping Conflict

Please see the below example of Presentation Definition and ID Token Mapping with conflicting field mapping.

Presentation Definition Sample

Notice the highlighted line of code that we are filtering the VC based on Type.

{
    "id": "vp_combined_email_user_profile_combined",
    "submission_requirements": [
      {
        "rule": "pick",
        "min": 1,
        "from": "A"
      }
    ],
    "input_descriptors": [
      {
        "id": "email_vc",
        "name": "Email VC",
        "purpose": "Check if data contains necessary fields",
        "group": ["A"],
        "constraints": {
          "fields": [
            {
              "path": [
                "$.type"
              ],
              "purpose": "Check if VC type is correct",
              "filter": {
                "type": "array",
                "contains": {
                  "type": "string",
                  "pattern": "^Email$"
                }
              }
            },
            {
              "path": [
                "$.credentialSubject.email"
              ],
              "purpose": "Check if VC contains email field",
              "filter": {
                "type": "string"
              }
            },
            {
              "path": [
                "$.issuer"
              ],
              "purpose": "Check if VC Issuer is Trusted",
              "filter": {
                "type": "string",
                "pattern": "^did:key:zQ3shtMGCU89kb2RMknNZcYGUcHW8P6Cq3CoQyvoDs7Qqh33N"
              }
            }
          ]
        }
      },
      {
        "id": "profile_vc",
        "name": "Country VC",
        "purpose": "Check if data contains necessary fields",
        "group": ["A"],
        "constraints": {
          "fields": [
            {
              "path": [
                "$.type"
              ],
              "purpose": "Check if VC type is correct",
              "filter": {
                "type": "array",
                "pattern": "^HITCountry$"
              }
            },
            {
              "path": ["$.credentialSubject.country"]
            }
          ]
        }
      }
    ]
}
ID Token Mapping Sample

At the same time, we have included the Type in the ID Token Mapping, which is now a conflict since there are two definitions of $.type in the Presentation Definition.


[
    {
      "sourceField": "$.type",
      "idTokenClaim": "type"
    },
    {
      "sourceField": "$.credentialSubject.email",
      "idTokenClaim": "email"
    },
    {
      "sourceField": "$.credentialSubject.country",
      "idTokenClaim": "country"
    }
]
Resolution

We should add the inputDescriptorId and change the idTokenClaim if you are trying to map same fields from multiple VCs to make sure the system know from which inputDescriptor from the Presentation Definition the value will be parsed. Another resolution is to remove the conflicting field in the ID Token Mapping if the field is not needed to be present in the idToken.


[
    {
      "sourceField": "$.type",
      "idTokenClaim": "email_type",
      "inputDescriptorId": "email_vc"
    },
    {
      "sourceField": "$.credentialSubject.email",
      "idTokenClaim": "email",
      "inputDescriptorId": "email_vc"
    },
    {
      "sourceField": "$.type",
      "idTokenClaim": "profile_type",
      "inputDescriptorId": "profile_vc"
    },
    {
      "sourceField": "$.credentialSubject.country",
      "idTokenClaim": "country",
      "inputDescriptorId": "profile_vc"
    }
]

Invalid Issuer URL

You may sometimes mistype the Issuer URL on your application configuration. If this happens, you may encounter one of the following errors:

  • getaddrinfo ENOTFOUND 03a4c36d-01a2-43e4-ad54-2fbbf19fa19f.apse1.login.affinidi.com

The Issuer URL uses an incorrect TLD, or the domain is wrong. Currently, the Issuer URL supported by Affinidi Login is apse1.login.affinidi.io.

  • "The Issuer URL is invalid. The 'Project ID' provided in the Issuer URL does not exist in Projects, or no Login Configurations were found."

The Project ID in the Issuer URL (https://<PROJECT_ID>.apse1.login.affinidi.io) is incorrect or no associated Login Configurations were found. Please check your Login Configuration for the correct Issuer URL value or ensure that Login Configurations are created in the project.