Resolving Common Issues
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:
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:
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.
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.
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.