Radius is a network authentication/authorization/accounting protocol. It operates at layer 3 in the OSI model.
Your web application operates at layer 7.
So there's a bit of a mis-match here. You might use Radius for authenticating network connections such as WiFi or network ports, but you need something http-based for your web application.
I'm making some assumptions, but it sounds as though you have a Radius server for authenticating users on your network, and have leveraged the same database of users for authenticating users in your web application. Whether or not the web app is speaking the Radius protocol to authenticate users, your users are not speaking Radius when they enter a username and password into a web page, so Radius is not going to help you with this - it needs to be done in the web application.
If your web application has access to the radius server, it might be possible to determine which user is authenticated, and authorize/OTP prompt based on that, but this is web application logic. No amount of configuration in FreeRadius can achieve this for you.
So I'd recommend taking a step back and considering where your user data is stored. While you might be authenticating against a freeRadius server, Radius is just a protocol, and at the backend there is a database of users. This could be an LDAP server, an SQL database, pam or just a plain text file.
Assuming you have a common user database, you can then add some kind of Oauth/SAML single sign-on application (Okta and PingID are some commercial examples) to the authentication flow of each service, so that a sign-on in one place takes effect in another. With SSO in place, you can either modify your web app to require the second factor at certain points (it would have to know the user's existing OTP secret, or you could require they set up another one for this purpose), or you could use some kind of policy and reauth if the SSO technology you use supports it.
In conclusion, I can't see a way to do this in freeRadius alone, and even if you could you probably shouldn't. And to do the authorization part you are always going to need to modify the application, unless you implement some horrible man-in-the-middle proxy which totally compromises security.