OAuth guidelines recommend using state parameter for preventing CSRF attacks, but in your examples for server-side code handling state isn't involved. It's practically the same when backend initiates sing in, a user authenticates on Google and Google redirects back to the backend with code and when frontend initiates sign in, the user authenticates with google and fronted receives code that is being sent to the backend. So in both cases backend needs state to verify, and sing in must be initiated involving the backend?
This plugin does not support the new Google authentication system(GIS).
You need to migrate by referring to this document.
I'm sorry to tell you this news.
OAuth guidelines recommend using
state
parameter for preventing CSRF attacks, but in your examples for server-sidecode
handling state isn't involved. It's practically the same when backend initiates sing in, a user authenticates on Google and Google redirects back to the backend with code and when frontend initiates sign in, the user authenticates with google and fronted receives code that is being sent to the backend. So in both cases backend needsstate
to verify, and sing in must be initiated involving the backend?