Why do you support sessions for an API (not REST)??
You remove the token and still get positive replies because the session cookie allows it.
At least the session in the cookie gets killed when the token is invalidated, but really, why?

It can be a game changer if you have high frequency APIs...

Saving let's say 32 chars per call, ASCII - 32 bytes...

1_000_000 calls... 32 MB saved.

It's... Tricky. Cause you need to be careful that the reauth doesn't swamp the server.

Well, I do not actually save transferred data, do I? Instead of having to provide the access token, I would have to provide some kind of session identifier, probably via cookie.

That would be

"Authorization: Bearer 00000000-0000-0000-0000-000000000000"

vs

"Cookie: session=00000000-0000-0000-0000-000000000000"

58 vs 52 chars, so only 6 chars saved, assuming your session identifier is as long as your token. A shorter session identifier might give you advantage here.

In any case, the API I'm ranting about is nowhere near high frequency, it's a user management API.

@DBX12 Yes... I'd assumed a rather long token or basic auth (base64 encoding overhead).

Regarding that it is a user management API...

This seems "shady". Security wise, auth renegotiation and session handling is far from trivial. Might seem trivial, but there are lot's of things that can go wrong. Especially when you have no security background.

An API isn't supposed to have a session behaviour, as adding a session means the API now has a lifetime.

Lifetime means it isn't stateless....

The session must exist on server side and client side.

Which is a thing that a regular API shouldn't do at all ... Cause that can give a lot of migraine and bugs, especially security wise.

Maybe research this a bit further, because there are very very good arguments against doing so.