I'm new to b2c so excuse me if my question is about something obvious.
There is a custom policy that is used for set password after registration. The policy is working fine and updates the password. If the same link is used again in the browser the policy correctly shows an error that the activation link has expired.
The problem is that if someone captures the HTTP requests and particularly the POST request that changes the password and sends it again in a tool with a new value for the password field it actually updates the password in b2c.
Could you please recommend how to secure this POST step?
You could add a CAPTCHA challenge as described by this Azure AD B2C sample.
This should prevent a direct replay of the registration step.
Related
This is my current scenario:
I'm currently using Azure B2C with user flows. I create a custom layout for my login with some scripts that hide the IDP buttons and take the domain email to redirect to the proper IDP(like a user journey).
The problem:
I can redirect to the IDP by adding the domain_hint param in the URL but I can't add the email to that specific IDP so the user has to put his email again. I've been trying to add the login_hint param to see if it works but the domain_hint cause the redirection so the login_hint param disappears. This is really blocking me because we want to improve the user experience.
Also, I tried to perform the redirection in the script(by fetching it), extract the response URL, and then add the login_hint. This seems to work fine but I got a CORs policy issue that is not allowing me to perform the request as I expected
Question:
Is there any way to perform the redirection with the domain_hint and also add the email using user flows? Is it only possible with Custom policies(IEF)?
Is there any workaround for this CORs policy issue?
Thanks!!
• Yes, it is quite possible for your application to redirect to the identity provider of your choice as specified in the ‘domain_hint’ parameter. This query parameter provides a hint to Azure AD B2C about the social identity provider that should be used for sign-in. Also, along with the ‘domain_hint’ parameter, if you want that during the user journey, the sign-in name should populate automatically and the user should provide only password, then you can use the ‘login_hint’ query parameter as shown below: -
Example: -
let loginRequest = {
loginHint: "bob#contoso.com"
extraQueryParameters: {domain_hint: 'facebook.com'}
}
myMSALObj.loginPopup(loginRequest);
• You need to know the domain name of your external identity provider and you need to pass these both the above query parameters in your application’s ‘MSAL loginPopup() method’.
For a detailed understanding and configuration of the above, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/enable-authentication-spa-app-options#prepopulate-the-sign-in-name
Also, regarding the CORS policy issues, I would suggest you to please refer to the workarounds and troubleshooting steps specified in the documentation link below: -
https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-understand-cors-issues#understand-and-identify-cors-issues
I am not this guy but I experience the same thing here. Also, there is this question but the author there uses a different flow, so I don't really know if it fits.
In short, I implemented the flow invite-via-email. I could generate the invitation link and the user could click on the link to sign up.
However, after signing up, the user is redirected to the main login page again. The user has to type the credentials again to sign in.
How can I implement auto signing after the user sign up with the invite-via-email flow?
There is a comment on that GitHub thread about id_token_hint something but I honestly do not get it. Many thanks.
If it helps, my setup is Azure Static Webapp with Svelte for frontend and Azure Functions for the backend.
Are you saving the access token from the first login? You might not be, forcing you to log in again. Also, do you have SSO enabled? This may help you if not. Please let me know and I can help you further.
Best,
James
I'm facing an issue with AzureB2C and SSO.
I've got a custom policy and a UserFlow, both using SingleSignOn-Scope "tenant" and both use the same federated IdP (AzureAD).
Now, when using the one flow for signing in, SSO is working. But when signed in and switching to another app which is using the other flow, I get "We're having trouble signing you in..."
Regarding the custom policy, I did not change the SSO technical profiles from the starter pack, nor adding any other claims to the relying party. The output token of both flows look the same
Any idea what could be wrong or how I could debug this?
Ok, I found out what's going on here.
In fact, UserFlows use different signing keys then custom policies. UserFlows include some reference to Microsoft-internal keys which cannot be used in custom policies.
Therefore, I guess, the session cookie is encrypted differently and cannot be used accross UserFlows-CustomPolicies.
The same happens if you protect your Api with a UserFlow-Policy and you have your UI use a CustomPolicy. The API will throw an invalid signature exception.
Conclusion:
You either stay with customPolicies or UserFlows throughout your entire infrastructure.
(Somebody should actually address this to Microsoft)
We have two custom policies written for our application - verify_email and signup_sign_in policies. We send a welcome email out (we do not use otp to verify email during sign up) to user with a link to the verify_email custom policy. The link contains a id_token hint signed by our certificate and the verify_email grabs the user principal from the id_token, gets the user from AAD, update the email_verified custom attribute then redirects the user to the application. This is a seamless process that doesn't show any UI to the user. The application will not recognize the tokens bec the tokens came from the verify_email policy so it will redirect the user to the sign_up_sign_in policy in adb2c and adb2c will see the current user session created by the verify_email policy and will redirect the user back to application with the claims needed without requiring the user to explicitly login.
What I have been seeing is half of the time, the sign_up_sign_in policy will not get the latest value of the email_verified claim that was recently updated. It seems like there is a delay that when you write the claim to azure ad, then read it sometimes what you get is the old value. Is there something that can be done regarding this lag to make sure I get the proper value all the time? Thanks in advance.
This is due to replication delay in the regionally replicated DC infrastructure. There is nothing you can do to influence this delay. You need to consider this as part of your workflows/design - eg, sign the user in using the id token hint journey, don’t ask the user to login again instantly. In this journey you’ll have all the up to date claims.
I have an Azure policy which works well for authentication users of different roles. I now need to add a SignUp component to this but there are some requirements that I'm not sure are possible.
I need the policy to return back to a different application than what called it. Say App A has the signup link on it's login page which will invoke the
policy's SignUp userjourney. However, I need it to not return back
to that same App, instead redirect to App B along with those claims
it's gathered. Is this even possible?
If it were possible (above), how can this be set up under the relyingparty
section? I would need to keep what is already there for the
userjourney that authentications users, but now also somehow provide
what's needed for this SignUp flow.
I am sorry if this is vague. I am just looking to get unstuck. If anyone could provide any sort of nudge in the right direction, I'd be very grateful.
This idea will not work. This is because, for at least the MSAL authentication library, it will reject a token response if MSAL was not the one who initiated the request. That is built in protection to most libraries, and uses the state parameter in the authentication request to apply this protection. Only responses that come back with the same state parameter will be accepted by the app.
You need to create a link from App 1 to App 2, and have App 2 initiate the Sign Up B2C policy.
The token response URL is controlled by the redirect_uri parameter in the authentication request. Your app will always require this to be configured within it. Both apps should provide a redirect_uri to send the token back to the respective App.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/openid-connect#send-authentication-requests