The issue you have not running through SSL isn’t so much the password (even though that is a big problem as well). Its more the fact that the users themselves are more susceptible to man in the middle attacks (MITM). So if you are pulling their name and email address etc etc from the Google auth, or even allowing them to enter in personal information to the app you’ve got to think about the external security. Not saying this would happen, its just what HTTPS / SSL is used for. Securing the information going from the website (or to the website) from the client browser to the server.
So it would app depend on the type of information your storing as to if https is important or not. Something also to bear in mind is that chrome has started classing pages as not secure that don’t run over https for the login forms https://developers.google.com/web/updates/2016/10/avoid-not-secure-warn (this would be countered if you use the SSO I believe though as it would go straight to google or facebook etc). In the future google are looking to make chrome show not secure on all pages that are not https but you dont need to worry about that for the moment.
I don’t fully agree with jarrad on the “bugger SSO” statement (sorry @jarrad !), as I think SSO is a fantastic thing that removes an extra barrier to sign up and means that users don’t need to worry about having to setup another user name and password. And dont forget those users are sitll yours, as long as you capture their email etc you still have contact with them, your literally just bouncing them to google or facebook etc for the authentication (pretty standard practice). However the only issue with that being their only option is, what if they dont have a google account, or a facebook or twitter account. You would still want to provide some form of manual account that isn’t SSO.
Hope that helps and is a bit of food for thought.