How does a user get authenticated on server B if they are already authenticated on server A through OAuth2?

Question

Lets say I have server A (a web server). Users initially use an external provider such as Google to get authenticated on that server. An entry is created in my database saying that this user has logged in before and has confirmed their account. They now have access to resources such as a forum available from the web server (so essentially we created a local account for them).

Now, the user wants to get authenticated on server B (a game server). Server B is accessed through a desktop app (game client) through TCP. Also, we have a gate server C that will handle initial requests from desktop clients before being able to connect to server B.

The entry created for that user previously, is required to access server B and/or C. Hence, the desktop app should open a browser to authenticate our user on server A.

What is the general flow required to implement such a system? My point of confusion is even if server C knows the user is authenticated (by exchanging access tokens with server A), what information do we pass to the desktop client and server B so when the client disengages from server C, they can be sure server B will not reject their connection attempt (assuming the request is legitimate)?

Answer 1

First I would define all the roles of all the nodes you have. Looking at your architecture I would pretend that gate Server(C) acts as an Authorization API Gateway which is responsible for managing the tokens which are needed for all authentication and authorization. WebServer (A) and GameSever(B) are the resources which require authorized user to access (using OAuth2 access token or other JWT)

I would define the flow like this:

1. User opens client desktop which directs him to sign-in using Google account.
2. Google responses with identity token (i.e. JWT token) and Desktop client send to Gate Server (C) with information of his client_id and resource he wants to have access (in form of scopes - i.e. game_server)
3. Authorization API Gate server (C) takes the identity token and on behalf of this creates an access token (or another authoriozation token in form of JWT) and sends to the client desktop which securely saves this.
4. On every call to Game Server (B) Client Desktop sends the authorization token and Game server checks that to authorize the request.

The important thing here is that you have to store the authorization token securely on the client side. This is not easy so I would recommend using something like a reference tokens. On this solution after Game Server (B) gets the authorization token he has to send it to Authorization API to get the token's content (claims). So, in this case, every request from Client Desktop to Game Server (B) results in additional request from Game Server(B) to Authorization API Gateway (C).