9

I am trying to configure the Microsoft Azure AD B2C identity provider in my Cognito user pool.

I am using the https://www.npmjs.com/package/@aws-amplify/auth library on my front-end.

I have named the new identity provider Microsoft. I have also enabled it on my user pool. And I am passing the same (Microsoft) to the Auth.federatedSignIn method.

Now, when I try to authenticate the user with Microsoft, the user gets authenticated from the Microsoft side but the Cognito gives me the ?error_description=Invalid+ProviderName/Username+combination.+Please+check+again+&state=XmnGedOhmT99RnTlw0LypyMmqwCRbCZr&error=invalid_request error.

This seems like a configuration issue to me but I am unable to figure out what is it.

Please help.

Anand Padiya
  • 143
  • 8
  • 1
    Hello, any update here? We are having the same problem, and it happens only for Microsoft OIDC, With SAML it is working fine. Are you linking users, I think there is some problem with linking if a user is not linked we do not have such a problem – Dragan Velkovski Jun 24 '21 at 12:44
  • 1
    Hello @DraganVelkovski, there is no update so far. We have parked the idea for now. Thank you for your valuable input. We will try with SAML and see if that works for us. We are linking the users but I am not sure whether the issue is because of that or there is some issue on the Cognito side. We will need to check we try for that integration again. – Anand Padiya Jun 25 '21 at 13:08

1 Answers1

4

After some time we managed to resolve this issue. The problem was that the user is linked with ProviderAttributeValue to lower case, but in the sub claim from the OIDC provider there are capital letters, and that's where the whole confusion was coming from. If the user is linked with the original value provided from the sub claim everything works fine

https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminLinkProviderForUser.html

{
   "DestinationUser": { 
      "ProviderAttributeName": "string",
      "ProviderAttributeValue": "string",
      "ProviderName": "string"
   },
   "SourceUser": { 
      "ProviderAttributeName": "string",
      "ProviderAttributeValue": "string" //ensure that value is same as in sub claim,
      "ProviderName": "string"
   },
   "UserPoolId": "string"
}

To have access to the original sub claim in for example the pre sign-up lambda, you should map the sub claim from the OIDC provider to a custom attribute, i.e custom:sub. The app client must also have read and write permissions to the custom attribute for it to show up in the lambda event user attributes event.request.userAttributes['custom:sub'].

jdnz
  • 932
  • 1
  • 7
  • 18
Dragan Velkovski
  • 318
  • 3
  • 14
  • Makes sense, but how can I get the non-lowercase version? I'm am trying to link the Microsoft OIDC auth to an existing account in the pre-signup lambda, but the lambda receives the userName already in lowercase. – jdnz Feb 28 '23 at 07:26
  • 1
    I missed that part. Thank you for updating my answer. We have also solved it with a custom field. – Dragan Velkovski Feb 28 '23 at 21:38