K
K
Kolya Vantukh2021-10-25 10:14:33
PHP
Kolya Vantukh, 2021-10-25 10:14:33

Should I check the username and password on every request to api(guzzle)?

I am making a simple api for my service (not SPA, simple queries through, for example, through guzzle), where I myself will generate passwords for access to different users. They will log in using their username and password. In the case of SPA, during login, a token is returned, by which api authorizes the user and the token has a lifetime, if this time expires, the user no longer has access to the api. In my case, issuing a token is pointless at all, right? Since requests can only be sent a few times a day, and just check the username and password with each request?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
I
Ipatiev, 2021-10-25
@vkolya

Should I check the username and password on every request to api(guzzle)?

Here, as always, in the title of the question is one thing, and in the text - well, quite another.
In my case, issuing a token is pointless at all, right?

True
But in the general case , which the question claims, judging by the title , it is not worth checking every time, but it is worth issuing a time-limited token by login and password when requesting a separate entry point.

D
DollyPapper, 2021-10-25
@DollyPapper

It is good to use tokens where the service is stateless, for example, in microservices, because sessions by login and password are scaled horizontally shitty. I think you are confusing a token and a regular password. The login should already be hardcoded into the token. In your case, if you do not plan to expand anything, use regular sessions. If you want to use tokens, you need them 2
1) Access token - the token by which the user is actually authenticated in the application. This token has a lifetime, usually quite short, 15 minutes.
2)refresh token - for this token, once every 15 minutes, the front sends a request to a specific endpoint and the api issues a new access token.
Why the hell do you need a refresh token? Very simple. If our access was stolen, and our application is stateless, that is, we do not store any state and information about user visits on the server, then we cannot block this token in any way, this is where the refresh token comes into effect. After 15 minutes, our access will become invalid and the client will send a request with a refresh token, in response api will send a new access and the token that the attacker will not have is valid.
In your case, yes, basic cookie authentication will do.

E
Eugene, 2021-10-25
@dragonesis

SPA or not SPA is not the point.
Where are you going to store the login-password pair? On the client? Safely? I think no.
Next, you should choose one of the existing authorization mechanisms and apply it to the project. It can be sessions, tokens, or something else.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question