Is there a way to increase the expiration time of OTP codes delivered via email during MFA and password reset? My users are getting the email later than 8 minutes and by the time they use the code, it is expired. What is the actual default? Is there a way to leverage the OTP technical profile described here Define a OTP technical profile in an Azure AD B2C custom policy ?
I believe the default expiration time is dependent on the method you're using to send them to code.
As far as I can tell from the documentation, the most customizable method for sending the OTP is using the OTP protocol provider you linked in your question.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/one-time-password-technical-profile
This protocol provider has a specific metadata item you can set for the expiration time (CodeExpirationInSeconds). It's min is 60, it's max is 1200 and it's default is 600.
If you need more fine grained control over the expiration time of the code, I would use this protocol provider to do it.
Related
I am using a python script that login to AWS account with an IAM user and MFA (multi-factor authentication) enabled. The script runs continuously and does some operations (IoT, fetching data from devices etc etc).
As mentioned, the account needs an MFA code while starting the script, and it does perfectly. But the problem is script fails after 36 hours because the token expires.
Can we increase the session token expiration time or automate this task not to ask MFA code again and again?
You can't extend the expiration, but you can circumvent the protections (at your own risk). In principle, you can store the MFA secret used to generate TOTP codes (e.g., what QR setup codes provide) and have your script generate OTP codes to perform MFA challenges automatically. For example, using the PyOTP library. Of course, if your MFA requirements require more than TOTP (like enforced biometrics or physical touch keys) then this won't work.
But it would probably be easier to just setup a solution that avoids the need for MFA to begin with. For example, deploy your script to run on an EC2 instance with an instance role with necessary permissions or create an IAM user that does not have MFA requirements.
Unfortunately not, the value can range from 900 seconds (15 minutes) to 129600 seconds (36 hours). If you are using root user credentials, then the range is from 900 seconds (15 minutes) to 3600 seconds (1 hour).
We have used Azure AD-B2C and implemented MFA using custom policy. We have authenticator app as one of the MFA option to login to our application.
We are using Microsoft Authenticator App and it generates the one-time passcode every 30 seconds. However, we are able to login to the application using the old TOTP that's generated before 30 secs.
I have verified checking the validity of the TOTP, but couldn't find any documentation on this. The code generated is sometimes valid up to 3 mins and sometimes up to 5 mins. Is the code not supposed to expire within 30 seconds?
Can you please clarify this, and refer me to any documentation.
As per all the documentation, TOTP generates the one-time passcode every 30 seconds, but nothing is mentioned about its expiry time.
As per TOTP algorithm, we can't control its expiry time and as name mentioned its one-time code which can be used only one time.
So even if you are entering the expired code, it is really not expired. It is just expired in the time slice when the app generated it, but Azure AD B2C will accept it within time tolerance (as per you up to 5 mins sometimes).
As this OTP can be used once, B2C will give you error if you try to use it next time.
One more factor is the code generation is based on system time, and while system time of Azure AD B2C can be synchronized with internet time servers, system time of mobile device can be out of sync for various reasons. Thus, Azure AD (B2C) has a time tolerance of to accept Time Based One Time Passwords during verification.
I haven't been able to find appropriate documentation related to this. But in my experience, the totp verify page (Not registration) allows codes of +/- 90 seconds.
In registration flow, the totp flow accepts code as old as around 24 hours. A common mistake that could happen is reading and writing the secret key while using the new totp flow. If you provide the secretkey value as an input claim to totp verification page, b2c treats it as a registration flow and goes ahead and accepts old codes.
I believe the reason for this to account for time skew in the user's totp device. The time in user's totp device might not be in sync with server time and totp relies on current time to generate the code.
Once you use a code from 2 hours ago for registration and if you try to verify with a new code (current time), the verification will fail. It will expect you to provide a code from 2 hours ago with a tolerance of +/- 90 seconds.
Azure MFA allows TOTP code in the range of 900 seconds (-450 and +450 seconds).
Not documented anywhere, found by experimenting
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.
Currently I am using B2C standard password reset policy for changing password. During password reset journey B2C sending code to email and validate code for password reset. Currently this code is expiring almost immediately. How can I extend this expire time.
The default expiry time for email verification code is 5 minutes and we can not extend it. It seems like you are getting emails after that time period.
For now you can disable email verification system. Please check the below documentation
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-disable-ev
I hope it helps.
We are using the API with Send on Behalf functionality in our system would like to check on the impact of the expiry of the SOBO’s user password on the API.
What will happen during the API calls when the password for the SOBO user has expired.
Alternatively, can we exclude those accounts from the password expiration policy?
If not, how should we go about ensuring that the password expiry does not result in failure of the API calls.
Password expiry is only enforced on logging into the WebApp. The general best practice is to have your API (or SOBO) user never use the DocuSign Web Application.
So, even if the account has a 30 day user password expiry it will not be enforced via the API and the password itself will only expire on a login attempt via https://account.docusign.com/#/web/login.