Локални PHP API и JWT, први део

Категорије:
  • ажурирања сајта

Кад желимо да направимо веб апликацију која треба да има могућност измене података, једно од првих питања на које треба одговорити је како ће бити решена веза између фронтенда, који је видљив корисницима, и бекенда, који чини погон апликације. Временом су се усталили стандарди за размену података, као што је AJAX, и формати представљања података, као што је JSON. Следеће питање које се намеће је како контролисати права приступа и измене података. Ако додамо могућност измене чланака или других елемената наше апликације, није згодно да та могућност буде доступна свима. Данас је један од најраспрострањенијих начина ауторизовања JSON Web Token, или скраћено JWT. Он функционише по принципу јавног и тајног кључа. Подаци који нам могу послужити за идентификацију чине JWT; они се потписују тајним кључем, кодирају уз помоћ Base64 и шаљу клијенту. Када клијент жели да приступи заштићеном ресурсу, уз захтев пошаље и JWT, који се декодира и провери дешифровањем потписа јавним кључем. Само јавни кључ који одговара тајном кључу којим је шифрован JWT ће верификовати податке. JWT се састоји од три дела: заглавља (header), главног дела (payload) и потписа (signature), који се после Base64 кодирања раздвајају тачкама.

Рецимо, за токен:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2dvb2dsZS5jb20iLCJhdWQiOiJodHRwczovL2dvb2dsZS5jb20iLCJuYW1lIjoi0J_QtdGC0LDRgCDQn9C10YLRgNC-0LLQuNGbIiwidXNlcm5hbWUiOiJwZXRlcnBhbjEyMzQ1IiwiYWRtaW4iOmZhbHNlLCJpYXQiOjE1ODY1NDE2NjEsImV4cCI6MTU4NjU0NzU2NSwianRpIjoiYTU3MWQ0NWItMTdmNy00N2I3LWJjM2ItZWRhMzFkN2IyNmIzIn0.Hb4Z6bsFFY2k-tshcCtQBOt768MAH0jmYWrnHshfaeM

Paste-овањем на сајту jsonwebtoken.io између осталог добијамо дешифрован JSON, који представља главни део, payload, JWT-а:

{
 "iss": "https://google.com",
 "aud": "https://google.com",
 "name": "Петар Петровић",
 "username": "peterpan12345",
 "admin": false,
 "iat": 1586541661,
 "exp": 1586545925,
 "jti": "a571d45b-17f7-47b7-bc3b-eda31d7b26b3"
}

Сва поља су потпуно опциона, али су нека од њих ипак стандардизована у стандарду RFC 7519. На пример, iat (Issued At) поље садржи Уникс timestamp времена креирања JWT-а, а iss (Issuer) ентитет који је креирао JWT.

Уколико се информације садржане у JWT-у тако лако декодирају, с правом се поставља питање безбедности JWT-а. Управо то је разлог тога да се не препоручује смештање осетљивих података као што су лозинке у payload. JWT служи само да успостави неку тврдњу, рецимо да је вредност параметра name ниска Петар Петровић. Тачност тврдње се проверава дешифровањем потписа јавним кључем.