REST API in Authorization (PHP)

Pa trenutno mora stranka dobesedno poslati takšen zahtevek v headerju "Authorization: token" kar mislim, da tudi ni najboljša praksa ali se motim?

Token se generira ob registraciji uporabnika in se shrani v bazo. Generiram ga s pomočjo spodnje kode (pobrana iz neta, zaradi random_int() je potrebna PHP verzija 7+).

function random_str($length, $keyspace = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
{
	$str = '';
	$max = mb_strlen($keyspace, '8bit') - 1;
	for ($i = 0; $i < $length; ++$i) {
		$str .= $keyspace[random_int(0, $max)];
	}
	return $str;
}

Če registracija poteka preko https (še nisem delal s tem protokolom zato niti ne vem, kako točno vse skupaj deluje, tako da malo ugibam), potem zakaj bi jaz sploh še potreboval neko spreminjanje tokenov ali ta oauth2? Saj si verjetno client in strežnik že prej izmenjata ključe, da lahko potem ustrezno zavarujeta podatke, ki se nato prenašajo, vključno z glavo zahtevka/odgovora, torej tudi podatek o "Authorization: token", ki ga pošlje client in podatek "Set-Cookie: ..." s katerim na primer dobimo ID seje, ki ga v odgovoru takoj na začetku pošlje strežnik. Torej zakaj bi se zdaj še nekaj trudil, da bi znotraj že tako kriptiranih podatkov, kriptiral še podatke za Authorization? Če pa prenos poteka po http, pa seveda lahko nastopijo težave ampak, če se ne motim, če že nekako zaščitim Authorization, ne zaščitim pa "Set-Cookie" oz. nato client requesta s podatkom o Cookie spet nisem naredil nič, ker če mi kdo prestreže pakete in dobi podatek o ID seje in teoretično, da sem takrat ravno prijavljen tudi sam, se lahko v aplikcijo prijavi tudi sam, kar je pa še slabše kot če bi dobil dostop le do api-ja Ok, če uporabljam http, bodo pač težave, če mi kdo prestreza promet Vprašanje pa je ali se lahko s https rešim vseh teh problemov in drugo, kako zelo, se je sploh vredno za običajne strani sekirati, v primeru, da poteka komunikacija preko http, na primer, ravno sem preveril bolha.com. Komunikacija poteka preko http, podatek o ID seje se nahaja v cookie BOLHA_SSID, če mi nekdo prisluškuje in dobi ta podatek, se lahko hitro prijavi v mojem imenu, preko kakšnega cookie managerja spremeni podatek za cookie in je notri, sem preveril pri bolhi in gre, torej nimajo nobene zaščite. Če bi prav čas začel prisluškoval, bi pa tako lahko dobil podatke o geslu in uporabniškem imenu iz POST, recimo. Malo sem zašel ampak s tem OAUTH2 bi se lahko pred vsem tem zaščitil tudi že pri dostopu preko http? Takole malo na blef bi se verjetno res dalo rešiti (zdaj spet malo ugibam, ker je moje kriptografsko znanje bolj kilavo) s simetrično kriptografijo (če se sploh tako imenuje), kjer bi potem bil en skupen token, ki bi ga imela server in client in bi z njim kodirala/odkodirala sporočila ali asimetrično kripografijo (RSA), kjer bi imel strežnik svoj privatni in javni ključ, client pa prav tako svoja dva, izmenjala bi si le javna ključa in potem bi client kriptiral requeste z javnim ključem od serverja, odgovore pa bi odkriptiral pač s svojim zasebnim ključem (podatke bi mu jasno strežnik zakodiral z njegovim javnim ključem), strežnik pa bi počel pač enako le da s svojimi ključi. A je to potem ta https://jwt.io/ (prvič slišim zanj)? Samo za implementacijo se mi zdi to strašno komplicirano.

Za na konec pa še tole čisto mimogrede, sem videl, da praviloma nekateri pod "Authorization: token" pišejo "Authorization: Basic token" ali "Authorization: Bearer token". A to je kak dogovor ali kaj? Ta beseda mi potem pri apache_request_headers() samo v napoto hodi, ker mene tako zanima le vrednost za token.