Godot Multiplayer - Player Authentication | Godot Dedicated Server #3

in this godot tutorial i'll teach you how to create an authentication process so that your players can log into your multiplayer games this tutorial will take large skill multiplayer games into account because that's what this series is all about let's get started i wish just for once that i could create an easy tutorial you know teach you all about authentication in 15 minutes but i can't because before i can teach you proper authentication processes we have to talk a little bit about network architecture and these couple of minutes are probably going to be the most important minutes of this entire multiplayer tutorial series so hang on to your hats and it might get a tiny bit complicated but i'll drag you through it and you'll thank me in the end probably so when you started this tutorial series or when you landed on this video in youtube you probably had something along the line of this in mind when you thought about multiplayer in games a number of clients connecting to a single game server with a database and everybody's happy well not so much because there's a number of serious problems with this architecture even if you can talk of architecture with something as easy and simple as this and two of the most important problems that i'll want to highlight here is first scalability a single e net protocol godot high-level multiplayer server is capable of handling up to about 4 000 concurrent connections 4 000 concurrent connections is a major achievement for any indie dev developer however if you reach that success you want to write the wave of success so you want to make sure that it's scalable and you can add more servers otherwise you have a number of planes dozens maybe even hundreds that are facing a login attempt field servers full message that's the last thing you want when you write that wave of success so you need scalability the second one is that this game server is connected to the internet the but it's also exposed to the internet what i mean by that is that that game server needs to be able to accept any ip address as a connection because any ip address is a potential player and with all ip addresses being accepted you also expose the database which holds the user data email addresses usernames passwords to the internet now that doesn't automatically mean that they're accessible and that everybody can just look them up but it does reduce the amount of layers of security we can implement within this architecture to make sure that we as game developers take our responsibility to keep the privacy the private data of our players safe and that is an important responsibility to take so let's switch over to what we're going to be teaching in this entire tutorial series uh and and how the architecture will look this is what we will be programming in this tutorial series and i know it looks like a lot but don't worry don't run away we'll take it nice and easy step-by-step authentication first but before i can teach you that proper authentication i do need you to abstractly understand what's going on in this little schema here so i'll take one minute of time to explain it and i'll make a separate tutorial video on where i go really into the high that why the how and the what of this uh this network architecture and also show you some slight variations that might fit the the type of game you're making a little bit better the authentication part is going to be staying the same in all those iterations that i'll be uh showing so don't worry about having to redo or undo things that that shouldn't be the case so without further ado the clients are going to be connecting to the gateway the gateway is exposed to the internet accepting any ip address the gateways plural because you may want to have several gateways maybe one for the americas one for europe and africa one for the apec area that way you can reduce latency the gateways are going to be connecting to the authentication server forwarding that login request they received from the client now the authentication server is only going to be connecting to a number of gateways and a number of game servers and because of that those limited connections and of course we know the ip addresses of those servers and gateways we can use ip filtering in the firewall of the authentication server thereby we don't expose it to the internet now that doesn't mean it's absolutely 100 secure there are things called ip spoofing where you can fake an ip address but it is yet another layer on top of other layers that we will be implementing for security to make sure that we don't lose any data that we shouldn't be losing and that's really how network security works it's not like a one-size-fits-all solution it's really layer upon layer upon layer upon layer to deter those that would like to get unauthorized access to our servers so the authentication server is of course going to do the actual authentication process it's going to be matching username and password with a database of usernames and passwords and on successful authentication it will generate a token and it will send that token to both the game server and the client so it will communicate back through the gateway to the client successful login and this is your your token and it will tell the game server you can expect a connection with this token so the token is going to be timestamped by the authentication server and it will only be valid for about 30 seconds or something like that next the client will try to connect to the game server and the game server will match the token the client provides with the token it receives from the authentication server thereby can be assured that that client has just been authorized by the authentication server to log in if the client is too late or if you would have somebody try and use the same token a second time couple of minutes later or next day or try and send it to your friend to also log in you'll see that the token has expired and is no longer able to be used that's why we secure our network so with that said we now can have a look at what we got so far from episode one and two and what we have to be doing in this episode to get that authentication working in the last two episodes we coded the client side and the game world side so we already have two executables now we have to also be programming a gateway and an authentication server bringing our project up to four different coda projects that is going to be a little bit more complex but once you have the gateway and authentication server established you usually don't really have to work on those that much anymore they are pretty lean in terms of coding you can afterwards focus again on your game server and your clients now the challenge of this tutorial is that if you have for example a look at the gateway the gateway needs to be able to have both a server connection as in the clients are going to be the peers the gateway is the server to which the clients connect but the various gateways are then pairs of the authentication server so we need to establish two network multiplayer e-net nodes within one single executable running at the same time that is really the challenge of this tutorial and what i'll be teaching you today so um we are going to be solely focusing on the authentication part the the the token with the timestamp and that being sent to the game server to have that verification process we'll leave that for another tutorial so we really focus on authentication today okay back in goto time to code i've already as you see on the bottom got four golda executables so that's the first thing you have to do you have to make two extra executables one for your authentication server and one for your gateway server now i've already coded everything in and we're going to go over everything step by step if i were to code live for you in this tutorial then this tutorial will be an hour long and you don't have the concentration for that so the first thing we'll focus on is the connection between the authentication server and the gateway that is going to be a very standard connection that you already know because it's exactly the same kind of connection that we already got between the game server and the client so we have a very standard piece of code exactly the same pretty much a one-on-one copy from what we did in episode number one the only difference was that left and right i changed some variable names so instead of max players we have mac servers and instead of the pair connected the player id now i have the gateway id that's being connected and i print gateway with a number connected and disconnected but like i said minor minor changes then we can go over to the gateway project so that was the authentication project now we go to the gateway project and the gateway project instead of putting the code on the main node of the server i have opted to actually run them both in a singleton so i have two singletons that are called authenticate and gateway the authenticate part is the connection to the authentication server and the gateway part will be what's going to establish the connection to the clients which we'll get to in a moment on the authentication part this also is pretty much exactly the same piece of code as we added to the client side in episode number one the gateways are a pair for our client i should say create client for the authentication server and we're just going to be connecting to the authentication server on that port number 1911 which is the same as on our authentication server 1911. it gets different when we have to start thinking about the connection between the gateway and the client the problem is or the challenge i should say is that when we create the server or the client we create the client for example right here and we set the network pair the network so the network is our e-net node on which we create a client with this ip address and that port that's all going to be stored in that network variable and then we set the network pair to that network we have been defining now that set network pair is a function of get tree what that means is and this is the back end of godot explained a little bit every scene tree comes with a built-in multiplayer api that multiplayer api is basically responsible for a lot of things making sure connections can happen that the connection between or the clients and the server are going to be pulling each other basically shouting to each other hey are you still here and then hey yeah you're still there um so all of that is built in it's integrated now we need this basically we took this slot already we took that multiplayer api that comes standard in your scene tree because that's what we need to connect to the authentication server but now this gateway also needs to become a server for the clients like i said needs to have that double connection that double e net note running at the same time so for that we need to go out of our ways and do things a little bit differently a little bit more complex so let's get into that moving to the gateway singleton so this is going to be the server side of the gateway that is going to be accepting connections from the client you can see that things are a little bit different from the top we still define our e-net nodes but now we also define a new multiplayer api and we stored it in our variable gateway api i now use a new port number not 1911 but 1910 and i set a maximum amount of place but that can have to be up to about 4 thousand then on the start server we again um tell the network that we've defined up there that this is going to be a server with this port number and the max amount of players but instead of using the get tree set network we now set custom multiplayer so we set a new custom multiplayer api using that gateway api right there that is of course the new multiplayer api now once we have set a custom multiplayer api we also have to set the root note and once you have this line of code this variable or this parameter custom multiplayer becomes available so we set the root node because that multiplayer api needs to be somewhere in the scene tree we can't set it to the root of the scene but we have to set or define one other node in the scene tree as the root now the singletons authenticate and gateway now they're just scripts but when you actually look at when the client is running you can see when you go over into the remote scene explorer you can see that there actually has two separate nodes in the scene tree so we're setting the root node of this new multiplayer api to self which is going to be the gateway singleton now once we've got that then we set the network peer network to that custom multiplayer so this line of code is basically the same line of code as we have in our normal server connection when we have this so here we take get three set network pair and on the gate we need we now use custom multiplayer set network peer so that's pretty much where we load that network up into the multiplayer api now with that done we now are running two e-net network multiplayer nodes high-level multiplayer basically uh in the same executable this of course also means that the client needs to be connecting to this and the client also of course on its game server already has that multiplayer slot on the tree in use that's what it uses to connect to the game server so when the client also needs to be able to make a connection to the gateway basically being a client to both of these servers we also need some separate code for that so i've made a new singleton in the client called gateway same name i'm not sure that's important for this one but i think it is so better make it the same name and we set the network the gateway api the ip address and the port number don't have to look at a username password yet and don't have to look at these four lines of code yet we'll get to that in a moment so we're going to start right here we take the create client we take network we create a client we again set customer multiplayer we again use that gateway api that we define on the top there we again define the root node to self and we again set that network pair on the custom multiplayer thereby now the client can also connect to the gateway while the gateway is connected to the authentication server and the client is able to also make a connection to the game server on a separate high level multiplayer network okay so with all of that set up we're almost there the only thing we have to do extra is we have to pull the multiplayer api that is done by default when you use the get tree set network pier there's a standard polling sequence happening in the background that you don't have to worry about when you create a simple multiplayer game but when you have a custom multiplayer api you need to pull manually so in the process function we are polling the custom multiplayer here using the poll function that is a function of the multiplayer api now you can see there's a number of circumstances that we do not want to pull because this connect to server will only be done once we hit the login button we'll get to that in a moment this custom multiplayer is not always set and if it's not set there's nothing to pull and if there's nothing to pull gold throws you an error so we first want to verify if get custom multiplayer is not null because in that case we just wanted to return and try again later then we also have to make sure that there is actually a network pair because if there's no pair to scream to hey are you still there and then expecting a reply then you're also going to get an error and again that that's not what we want we don't want errors it's not good so also if there's no network pair then we're also going to return and if those situations are not true then it's just going to continuously pull and that might sound very intense but it's not this also happens in the standard uh get in your standard scene 3 in your standard multiplayer api slot that is pulling all the time as well so this is not like something weird this is very standard we also have to do exactly the same on the gateway so also in the process function on the gateway there's also custom multiplayer polling happening but here there's less circumstances that we would not want that to be going on because when we start the gateway server we under the ready function start a server and we load the custom multiplayer so the gateway always has that custom multiplayer loaded so there's not a situation where that is not the case so we need one less exception here and we can slim the code down with two lines so with all of that set let's now have a look at actually how the authentication process is going to be going through all these different servers and ending up back at the client with a result now of course for authentication we need our player to be able to fill out a username and password so i've created this rather easy simplistic user interface for our login screen i will not go over how to make this because i'm trying to keep my tutorial shorter believe it or not um so i'll create a super quick tutorial on how to do this and upload it today or tomorrow in case you don't know but i assume you do when you're watching this sort of intermediate level multiplayer tutorial so if we play only this scene you'll see that here we can fill out a password and a username right now the password still shows letters but if you want that to go away you could very quickly go to the login screen you will be able to go to your your edit text and you could set this to uh to secret and that way you can have all those letters disappear but for now for demonstration purposes i'll keep it open and exposed so that you can see when i'm filling out the wrong and the right password so this login screen has a little bit of code not too much we define the username input and the user password input so that is basically the two text edits that are going to be typing the text in and we define the login button we have connected the signal of the login button of the pressed signal and we've connected it up first it's going to be checking whether we've actually filled out a username and a password because if both or are either of the username and the password are empty that means that we don't have to make a connection to the gateway server because we can already tell that there's never going to be a positive authentication result so when you have not filled both of these out you're not even going to try and make a connection and we now have here print please provide valid username and password but of course you would have to program a sort of a pop-up in there to make sure that your player gets the right feedback else we're going to be disabling the login button we do that and we disable that button until the result from the authentication server comes back or when there's a timeout i've not programmed that timeout in yet but the reason we want to do that we don't want somebody to start slamming that login button a hundred different times and then having the gateway was get all these connection requests and forwards all these authentication requests and then most likely somewhere in our servers there's going to be something blowing up um as in a bug is going to appear or an error appears and you know that way a player could drag down the whole authentication server so we don't want to be able to send two authentication requests out at the same time so we're going to be disabling the login button the moment the player pressed it and there was valid text input so we define the username as the the text box and we get the text we do the same for the password and i've done everywhere in the code i've done a lot of prints so that we can follow in the editor what's actually happening so we're printing okay we're going to attempt to log in then it will call the gateway singleton and it will connect to the server so in the gateway we now have not got under ready we don't make the connection automatically we are only going to be making this connection when the player presses that login button in the previous tutorials we have automatically connected to the game server through a connect to server under the ready function i've taken it out i've put a comment here so also we're not automatically connecting to the game server anymore it's an important note there okay so we're on the gateway the gateway is going to be making that connection so it's going to be connecting to the server and now these four different variables or these four elements here become important the connector server is going to be receiving that username and password that's what we've done in the login screen when we connect to the server we push that username and password to it so we have the username and the password we defined that in two variables on the top here so that we can use them later on and i'll get back to these two lines in a moment so once we have made that connection is that connection is either going to fill or the connection is going to succeed when it's filled well we'll print the the standard print that we've already had in the previous tutorials we'll also need some sort of a pop-up with that the server is offline or something or wasn't able to connect to the authentication server you need to send a signal to your player like hey something went wrong please try again now in that case of course we also have to make sure that we enable that login button again because else there's no second attempt possible so we enable that button again on a connection successful so that means that the client and the gateway are now in a connection only then that signal has been triggered we can run the login request so that's actually when we start the communication and so that happens automatically but only automatically once the connection is there because if we fire the request login before the connection has actually been established that is going to go and never arrive so that basically triggers this function the request for login so we're doing another print here because all these prints are going to help us with following the signals of course once you actually release your game remove all these prints because that's just server overhead you don't want that we're going to rpc id call number one so that's the server we're going to run the function login server login request and we forward that username and password the moment we do that there's not a single reason anymore to retain the username and the password in variables on the top here just for security reasons whatever i don't know malware or or sniffers or packet sniffs or whatever i'm not sure what we'll be able to get it out of here but if we don't have a reason to have it in there we shouldn't have it in there so we're just going to be resetting that the moment we've sent them away to the gateway server we just erase the variables on the client side so now that login request goes to the gateway so we switch to the gateway project on the gateway here we have the remote function login request so that's what's going to be triggering so we have a login request received you see i continue these prints i will i'll stop mentioning it now and we basically define the player id that made the request now we're gonna get the rpc sender id but do take note when we for example have a look at the game server that we programmed in the first tutorial we when we receive a remote function um not this one we need a game server sorry uh when we receive a connection we define the player id and when we define the player id we get 3 get rpc sender id this get 3 is that standard multiplayer api that is loaded into the standard slot of the scene tree that's how this function works it basically gets the default multiplayer api so now on our gateway you can see that we also get that player id through get rpc sender id but we have to take it from the custom multiplayer api otherwise we're going to get errors or it returns zero that's also possible so once we got the player id that made the original login request we then call the authentication or authenticate singleton on the gateway we authenticate the player and we forward the username the password and the player id we don't need the player id anymore in the authentication process because just that's just a pair id in the network but that player id is going to piggyback along for the ride except once the signal comes back to the gateway it made that loop we still know which was the which client was the original requester so we go to the authenticate script so that is now the interface to the authentication server where we run that function authenticate player this is going to be rpc one calling the the authentication server it's gonna call the function authenticate player with the username the password and player id piggybacking along for the right now we can switch to the authentication server which is going to be remote functioning this authenticate player this this script is going to run so it receives authentication request it determines which gateway requested or made this uh pushed forward this login request because we need to also make sure once we got several gateways that we send that signal back to the right gateway because that player id that client will only be connected to that gateway so we also have to retain the gateway id what we want is we want to get some results of this authentication first is we'll check whether the username exists in the first place if it doesn't exist it means that the player doesn't have an account with that username so either misspelled the username or doesn't have an account yet so the user is not recognized and the results are false if that is not the case it will check the password if the password is the same if not then we have an incorrect password and the result is false and else we have a successful authentication and the result is true now as you can see we're only working with a boolean here we're not going to send back whether the username was wrong or whether the password was wrong because that's information that the player doesn't really need we can just tell the player look something was wrong either your username or your password please double verify and try again we don't have to tell them well your username is known but your password is wrong if we send that information to the player that if that information is intercepted somehow that means that we have one less layer of security because now a potential hacker would know hey that's a valid username now all i need is the second piece of the puzzle and the password so it would provide more information to those of uh that have bad intentions let's say so we're only going to be communicating true or false nothing more we're not going to tell what what went wrong or what was false so once that is done we are going to take the rpc id and we use the gateway id so we're going to communicate back to the gateway with the authentication results function and then we communicate the results and that player id that have been piggybacking along for the ride all along then we go back to the gateway on the gateway we have the remote function authentication results then it will have received those and we'll apply those to the player we're going to call the gateway singleton so we return from the client slide to the server side of the gateway where we're going to run the function return login request with the results in the player id we switch singleton under the function here we're going to rpc id called the player id that had been piggybacking along for the ride all along we returned the login request with the results then we disconnect that player from the server so the gateway decides that that player should be kicked from the server the login request is done the loop is finished we no longer need you free the space of this gateway for other players to find a connection that way you can have up to maybe 10 or 20 game servers running and you only need maybe one or two gateways because the gateways will not have the amount of concurrent players that are at that point in time playing the game on the game servers otherwise you would need a hell of a lot of gateways anyway we disconnect the client after we done the rpc id call so that means that the call goes out to the client so the client is going to be on the gateway receiving that signal now it receives the results if the results are true then we run the game server singleton connect to server so instead of having the connect to server start automatically under the ready function this connector server is being initiated the moment where were we gateway i'm sorry the moment a positive result is returned from the authentication server via the gateway now of course right now somebody will be able to just adjust this code and just make it connect to the game server automatically and that is where the token is going to come in uh once we program that in a future tutorial it will also connect to that server using that token being received from the authentication server and that's how we make sure that people cannot bypass the authentication process now if we have a successful result we no longer need that login screen at user interface panel so we're going to re-free that away from the graphical user interface no longer need it else if the result is false we probably want to provide a pop-up with please provide correct username and password again we are not going to be identifying what was wrong we just know something was wrong just verify your username and your password and good luck then of course we also have to be enabling again that login button that we disabled when we pressed login so that the user can make a second attempt and we're going to be disconnecting our connection field and connection succeeded signals that we have set up connected here on the top when we made the connection with the gateway server we need to disconnect these two signals because if the player needs did something wrong wrong username and clicks login again these signals will try to reconnect again and when they try to reconnect the code will throw an error saying these two signals are already connected you cannot connect them a second time so to make sure that that error doesn't uh is not thrown at us we have to disconnect these signals here so that it can be reconnected in case the player makes a second login attempt did you follow probably have to rewind it a couple of times on pause i understand i understand so what we'll do now is we'll test it we'll play it we'll do it and i'll show you how it works so okay to test this we'll first have to start up all our servers so we'll start with the authentication server first we'll hit play on that and we have authentication server started here in the output we also run the game server that's not going to have any connections from the start but we need to have that running anyway so here we have server started on the game server then we're going to start the gateway so we press play on the gateway here we get a gateway server started and we get it successfully connected to the authentication server because remember there's two network uh e-net nodes on here and now we can check the authentication server now we also have a gateway with this peer id connected so that seems to be working just fine now we can play the client and on the client we can start well let's first check if we only do a username uh let's let's put the proper username we forget to put in the password we log in we get a message here please provide valid user id and password that's where we captured it before even sending it out to the server now let's fill out a wrong password so the password of course is test one two three so we'll do test one two we forgot the free we log in so here we get the whole the whole system attempting to log in successfully connected to connecting to the gateway results received please provide correct username and password that seems to be correct if we have a look at the gateway here you also see that we have a user connecting login request received sending out the authentication request results received and replying to the player and we disconnect the player because that's what the gateway does it disconnects the pair if we have a look at the authentication server we see that authentication requests received starting the authentication incorrect password so it figured that out an authentication result sent to gateway server so that all works well now of course the question is do we actually oh we do have to go into the actual executable in where we played can it recognize when we do it correctly so i'll add a free now we have the correct password we log in and now you see at the final here we have a successfully connected to game server and now i can simply shoot at this wherever again and you can see what we programmed in the first tutorial where the damage is communicated back from the game server is now working and we basically have the same situation as what we had at after episode number one of this series only now we have a proper authentication request that lays out the foundation that we need to implement the various security meshes and the scalability that are going to be normal for a larger skill multiplayer game that was it for today guys hope you like it if you did smash that like button hit subscribe don't forget that little bell icon to make sure that you don't miss out on any videos also if you want to support the tutorial creation process here at the game development center make sure you check the join button what options are available to you i'll come real fast with that tutorial on the user interface panel how to create that although i think most of you will know how to do that you might be interested in that if you watch this tutorial more than 24 hours after it has been released it's probably going to be linked up here somewhere in the suggested boxes so hope to see you next time until then keep on gaming keep on coding see you later guys

Channel: Game Development Center

Views: 11,904

Keywords: Godot Multiplayer, Godot Player Authentication, Godot Player Login, Godot Network, Godot Multiplayer Tutorial, Godot Server, Godot Dedicated Server, Godot Multiplayer Server, Godot Server Structure, How to make a multiplayer game, Godot MMO, Godot Beginner Tutorial, Godot 2d Tutorial, Godot Tutorial, Godot

Id: 6pfN6NFxQQc

Length: 34min 21sec (2061 seconds)

Published: Sun Sep 27 2020