First step in creating my new suite of react frontend applications is to make a simple Authentication server/service in Go preferably, where users can authenticate with their google account which will either result in:
I realize that I will get a JWT from the Auth server/service with the usual claims such as:
{
"iss":"accounts.google.com",
"at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q",
"email_verified":"true",
"sub":"10769150350006150715113082367",
"azp":"1234987819200.apps.googleusercontent.com",
"email":"jsmith@example.com",
"aud":"1234987819200.apps.googleusercontent.com",
"iat":1353601026,
"exp":1353604926,
"nonce": "0394852-3190485-2490358",
"hd":"example.com"
}
So far so good, but after that I'm not really sure what fields I need to store for the user "table" (using a dgraph db, but I guess it doesn't matter if it's a relational or graph db) in the database other than the email, which will to my understanding be the identifier pairing the user in db with the JWT?
How do you handle integration with your own database:
Do you store the token in the user table along with the email? In that case what to do if the token expires/changes and what about security?
So the question is not about how to get a token, it's about how to connect the user in the db with the JWT user that just got authenticated.
Most tutorials and articles I've read does not describe the database part in much detail.
Creation a new user in the database
In principle, you only really need to store the user's email (along with whatever other information your system needs internally for that user) to be able to 'link' your user with the "external" account they are using to login.
Login if matching user is found in db (how to determine match without password?)
One of the main reasons to rely on an external authentication mechanism is that you don't need to perform any password storage/validation yourself.
You just need to match the email the user is using to authenticate with the email you have stored in your DB.
Couldn't others just make a false token with the same email?
No, they cannot, otherwise this would not be useful at all.
Tokens are signed by the authentication server, and it is not possible to "sign" the token without having the authentication server's private key.
How to verify this in a safe way
See here: https://developers.google.com/identity/sign-in/web/backend-auth
Section "Verify the integrity of the ID token" discusses how you do this either by yourself or by calling an external endpoint.
Do you store the token in the user table along with the email?
You only need to store the user's token if besides authenticating them you plan to use Google's APIs on behalf of the user.
In that case what to do if the token expires/changes and what about security?
See here: https://developers.google.com/identity/protocols/OAuth2
You will need to store both a token and a refresh token, and there is a flow to follow in order to refresh it.
About security, you need to make sure no user is able to see other user's token, since the token enables an application to make requests to the API on behalf of that user.