mysql

>>106870885
>billion
1,000,000,000=1GB

>>106870906
This is more retarded than op. An account's data wouldn't be 1 byte

>>106870890
This
It doesn't take a lot of storage to store text data. It is practically nothing compared to storing pictures and videos.

>>106870885
If your website has billions of accounts, you can probably find a way to monetize it to pay for storage.

>>106870890
Get with the times gramps, we use postgres now.

>>106871283
>she's rolling her own auth
still a red flag. you are getting hacked.
use firebase.

>>106870928
Of course not, but he's making a good point. Let's say for example it's 200 characters per account, enough for basics, that's still just 400GB which fits on any computer these days. With a BILLION accounts which only the top 10 biggest services have.

>>106872496
>she's rolling her own auth
>still a red flag.
It's not hard, anon.
>use firebase.
Terrible idea, if you can't do basic auth, you can't configure firebase. As evidenced by the thousands of insecure firebase sites.

>>106870885
data in a relational database is usually really compact unless you're doing something wrong. at some point once you max out your hard drive, databases have to be scaled, by storing parts of the database across many different servers.

In general these kinds of situations have already been abstracted away and managed database services do it for you "so you don't have to".

>>106870885
You store user name and encrypted password in a database
When a user login, he provide your server with user and password
You validate it in server side, generate some kind of oauth jwt code and sent it to the user
Your frontend on users side save this jwt in a local cookie
You validate every request here after to the server with that jwt
Much of it have been implemented by most boiler plate code these days

>>106870885
>cost a lot of storage?

No. Most sites won't have billions of rows of transactional data in a table, if they do, you're popular enough to afford a few petabytes of storage.

that's why you hire auth specialists, op.
their job is to remember all the accounts.
they're amazing people.

>>106872496
>hacked
>firebase
have a tea

>>106870885
math hard innit?

>>106870885
You can store billions of accounts in a sqlite database.

>>106873572
>You store user name and encrypted password in a database
You would hash the password using e.g. argon2id.

>You validate it in server side, generate some kind of oauth jwt code and sent it to the user
You can use a jwt and lots of people do, but it's bad for auth because you can't cancel it on the spot for that user. Better to send a session token and store the hash of it in the db. And it's ok to use e.g. sha-256 for this since the session token will be randomly generated server side.

>>106870885
>won't they cost a lot of storage?
not really no
text is very light; site with couple dozen million users and a few billion rows of data here and weighing in around 480GB for the DB

>>106871283
actually mysql is far more prevalent for large websites, anon
postgres' whole value proposition is in its extensions, and at any serious scale you use more specialized datastores for those kinds of things
eg: timescaledb; great for low-scale time series data, but is utter ass (by about 2 orders of magnitude) than something like clickhouse
and for actual insane scale, basically everyone runs vitess (ie mysql) or cassandra, and nothing else even remotely compares

>>106873806
>You can store billions of accounts in a sqlite database
great for device-local storage (eg application preferences or the likes), absolute meme for all other cases
stop buying brainded tech youtuber slop ffs; surely you people can't be this credulous
you aren't gonna run 1 single fucking instance of a DB that cannot do concurrent writes for a million-users site...
just think for 30 seconds idk

>>106873832
>Better to send a session token and store the hash of it in the db
you're confusing a JWT with the content of a JWT
the whole JWT spec and Authorization header is nothing more than an alternative to eg the Cookie header
the content of a JWT is already typically the combination of a session id and some user info
the benefit is that you can bake in extra metadata in the JWT that avoids you needing the extra DB roundtrip for every single request
this could already be put in a cookie or something before; there's no distinction here
the reasons we don't check the DB on every request these days is cause it's expensive as fuck at any significant scale
much better to do short-expiry JWT and a negative cache for forcefully expired sessions in the backend, which then denies a JWT without a dedicated DB roundtrip (eg with a scheduled fetch of a KV set of expired sessions)

(cont.)

>>106873955
>the content of a JWT is already typically the combination of a session id and some user info
and before someone has a fit over this: signed cookies are WAY older as a concept than JWTs. the whole JW{K, T, ...} thing is just a formalization of good auth practices people had been doing for years
and not put into the "Cookie" header because browsers have utterly retarded policies with how those works due to 20 years of abuse and vulnerabilities
but absolutely nothing in JWT is new
if one thing is kinda new it'd be the oauth spec, and none of it needs JWTs specifically to work; you could just as easily implement it with a different transport syntax/format; the world just picked JWT because half the web is JS and that was good enough ™, if verbose