A
A
ASiD2020-04-11 19:39:51
PHP
ASiD, 2020-04-11 19:39:51

What authorization to do on the site?

Good afternoon. There is a public site. It is necessary to make authorization for users.
I used to make sites in PHP, used authorization through cookies and sessions. New site on ReactJS (frontend) + PHP (backend). I found on the Internet quite a few different options for organizing authorization, but I can’t decide which one is better to use in my case. Now the site is on one server, but there are growth prospects.

Tell me which authorization to choose in 2020? So to speak best practices.

Answer the question

In order to leave comments, you need to log in

3 answer(s)
D
Dmitry Komchev, 2020-04-11
@Lebezniy

You can consider using JWT in PHP: Authorization on the site with JSON Web Token

K
Konstantin Nagibovich, 2020-04-11
@nki

Make an authorization option through social networks.

A
Alexander Filippenko, 2020-04-12
@alexfilus

The simplest is to use standard PHP sessions, just set up storage in redis, or something like that.
https://gist.github.com/Alexfilus/0c55972103f28699...
Here is an example. The only limitation is that the session storage must fit on one server. You say that there are prospects that the site will no longer fit on 1 server, but what exactly will no longer cope with the load? Usually this is not PHP, and not Redis, but the main RDBMS.
There is also an option for sticky sessions, but this is already a crutch.
The classic JWT is good for everyone, except that it is the overhead of encryption - decrypting signatures, and it is impossible to make a button like "Log me out on all devices". That is, even if the user suspects that his password or JWT token was stolen from him, he will not be able to log out the attacker, even changing his password. Just wait until the token expires.
The option with access_token and refresh_token is often recommended. This is quite reliable, and you can manage their storage, but in fact, the same sticky sessions.
In general, it is best to make an authorization microservice based on sessions, and as long as this microservice is able to live on one server, do not touch it. And such a simple thing should withstand thousands of requests per second per 1 core.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question