Now it's important to understand how authentication works because if you're having a web development
background, you might be used to authentication working a bit differently.
So we have a server, Firebase in our case but that can be any server to which we talk from our React
Native mobile app
and this is the server which typically also authenticates us, so where we can send the email and the
password the user entered to create a new user or to log a user in,
so we send that auth data to the server.
Now the server responds with something, for example with an error if the credentials are wrong or with
a success response if they're correct and in a traditional web application, a server would then also
store a so-called session on the server and return a session key to the front-end,
so to the browser for example that basically allows the browser to find out that the user using this
app in this browser is authenticated.
Now this works a bit differently for mobile apps because there, you communicate with servers which are
stateless, for example RESTful APIs or GraphQL APIs
and there you don't really have a session because the server doesn't care about the individual clients,
it doesn't save any data about whether you are authenticated or not,
instead you work with so-called tokens.
The idea is not too far away from the session idea.
When you login and the server checks the e-mail and the password and determines that both is correct,
the server creates a token,
it uses a certain algorithm for that and it uses a key, a private key which only the server knows. This
token is then returned to you,
so to your app, for example to React Native mobile app and there you can store the token in some storage,
for example in the Redux storage,
so in memory, manage it with Redux in memory whilst your app is running.
Now why do we need that token? For one, as long as we have that token, we can determine in the mobile app
that the user is probably logged in and therefore forward the user from the authentication screen
to our main app screen and so on and when the user clicks logout, we would simply delete that token
but we also need that token for something else. On the server, as I mentioned we typically have certain
resources, certain URLs which are only exposed to logged in users,
so for example in our app, creating products is probably not something every user should be able to do
and therefore if you want to send the request to such a protected resource, you need to attach that token
to the request so that the server which created the token and which therefore can check with that private
key whether the token is valid, so that the server can determine whether you have access or not.
If you send a wrong token or an invalid token or no token at all, access will be denied and you get back
an error. If you have a valid token
and again the server is able to check whether the token is valid or not, you will be granted access and
you can therefore then access the resources, write data, whatever it is.
This is how authentication works
and this is how we will implement it here.
Now the good thing is Firebase which we're using as a dummy backend already has all the token creation
user management stuff built-in, so we don't need to worry about that,
we just need to send the right requests and then manage that token and we're good to go.