My question is what is the risk of doing such thing
You are exposing an application running on an internal system to the wild internet. If a feature or bug in the application allows for example remote code execution then the attacker will be able to execute this code on your machine and thus inside your local network and thus might reach and attack internal systems in your network which should not be accessible from outside.
... only giving access to the authenticated user to port forward?
My initial interpretation of this question was that you as the one exposing the internal application wants to restrict which external users could connect to this forwarded port. But there is no authentication at this level, i.e. it is simply a TCP port which is reachable from outside for everybody. Any kind of authentication need to be done in your application. Only, this is then done again at your internal systems which means problems before or during authentication might again affect your whole internal network.
Based on your feedback it looks like you switched roles for this part of your question, i.e. no longer being the one which wants to make its application accessible but instead being the administrator who wants to prevents this. In general: if the user has only restricted access via SSH (can execute selected commands) then one can limit also the port forwarding (option no-port-forwarding
in OpenSSH). If the user instead has full shell access he can work around such restrictions.
is there any other way around without using third party apps like ngrok?
ngrok is not a simple broad port forwarding but instead allows to publish the application only for selected users by requiring authentication. If this restricted access is used the risk is greatly reduced, i.e. only users which know the URL and have the authentication credentials can connect. Still, if you cannot trust these users to keep these access credentials private and also to not attack your system then you should not do it.