Oauth2 in Single page applications

Im trying to figure out how to implement Oauth2 sign in, e.g. google and github login via a React Single page login + phoenix backend combination.

Basically this is the flow i’m assuming:

  1. User clicks sign up/in
  2. React sends message to backend requesting url -> url is presented to user and opened?
  3. User signs in, via e.g. google and a token is sent directly from google back to the phoenix server (ueberauth).
  4. I then save that information back to the database including email, and token
  5. I then sign a JWT using something like guardian

Questions I’m struggling with are:

  1. How do I at step 5 get a message to the browser saying ‘here’s your token’
  2. What do I use the token I get back from google/github for? is there even a use for it? Am I suppose to hit google every request and make sure they are still logged in or do I just ignore it? I can’t see any use for it considering I’m using a JWT for app/server communication
2 Likes

I actually think I might have come up with a solution from a bit more reading.

Is this ok/no security holes

  1. User clicks ‘sign in via google’ or something in my react app.
  2. Then in my react app I redirect my user to my api /api/auth/google ueberauth route.
  3. I the user does the auth dance with google and the result is sent back to my api
  4. My api does a DB lookup to see if the user is already created. If they are it signs a JWT (using guarding) and returns that in the response headers.
    4b. If they are not, it creates the user in the backend, then generates a JWT and again puts it back in the header along with some other information indicating that they are a new user and may need to do some more sign up stuff.
  5. I then redirect back to my react app with the JWT in the redirect headers.
  6. Authentication happens as normal from then on using the JWT.
  7. ON sign out, I delete the jwt from their local storage and when they sign in again the process repeats it’s self.

How does this look?

2 Likes

Sounds fine on initial look, though I’d not use JWT since you are communicating with your own front-end app and not having it pass it to another server. ^.^;

So you check for an existing account in the DB and sign a token (to be returned to the JS front-end application for future requests) only by relying on the email address returned by the oauth2 provider?

1 Like

@acrolink yeah pretty much I think (Not 100% what else ueberauth is doing under the hood) -> you see any issues with that?

2 Likes

@acrolink also looks like the google strategy then makes another request on callback to obtain an access token:

  @doc """
  Handles the callback from Google.
  """
  def handle_callback!(%Plug.Conn{params: %{"code" => code}} = conn) do
    params = [code: code]
    opts = [redirect_uri: callback_url(conn)]
    case Ueberauth.Strategy.Google.OAuth.get_access_token(params, opts) do
      {:ok, token} ->
        fetch_user(conn, token)
      {:error, {error_code, error_description}} ->
        set_errors!(conn, [error(error_code, error_description)])
    end
  end
2 Likes

@Harrisonl, I have inspected some popular Rails gems, they do the same: authenticate the email returned by the second Google API call if it exists in the DB, or create new record for if it’s new.

Hey on step 5 do you mean that usually you return json, but in this case you redirect back to the url of your client with the header?
Do you somehow pass the url through the whole process or just use a static one ?