Oauth2 in Single page applications

Questions / Help
,
1

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
2

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
3

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. ^.^;

4

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
5

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

2 Likes
6

@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
7

@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.

8

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 ?

9

Hey, did you get to figure this one out?
I’m trying to accomplish the same thing but on point 5. redirect I get confused. How do you pass the JWT back to the client?
Is this supposed to work?

{:ok, token, _claims} = Accounts.Guardian.encode_and_sign(user)

conn
|> resp(:found, "")
|> put_resp_header("Authorization", token)
|> redirect(to: "/#")
10

Just for the sake of not having somebody replying to my last answer, and as I think it may be interesting:

I took a look at how this is done at CaptainFacts’ and decided to do the same. Here’s my list of steps, based on what’s been written by @Harrisonl

  1. User clicks ‘sign in via [thirdparty]’ or something in my React app.
  2. Still on the client’s side, create and use the third party’s oauth url to redirect or open in a new tab. Here’s CaptainFacts’ repo example.
  3. The user does the auth dance with [thirdparty] and the result is sent back to React.
  4. Now is when React does the signin with Phoenix via an API POST. E.g. in this line.
    4.a Existing user is retrieved and maybe updated and JWT token gets sent.
    4.b Or new user is created and JWT gets sent with maybe extra information.
  5. React gets the JWT as a regular login response.
  6. Authentication happens as normal from then on using the JWT.
  7. Sign out is performed by unlinking the third party from the user, and removing the local JWT.
1 Like
11

Hey I ended up on something similar, the client does the 3rd party sign in, and then the token is being sent to the server to validate it and sing the user in.

1 Like
12

hey @pehuen-rodriguez - sorry for the late reply just saw this.

But yeah that sounds perfectly reasonable - I think what you described is called the implicit or client side flow which is 100% fine from my understanding. I actually used the exact above described flow before.

Just remember to be careful how your using/storing the JWT in the client!

1 Like