ორი token არსებობს პირდაპირი კონფლიქტის მოსაგვარებლად: access token უნდა გაიგზავნოს ყოველ მოთხოვნაზე (ამიტომ ის ბევრად არის ექსპონირებული), თუმცა ასევე გინდათ სესიები, რომლებიც დიდხანს გრძელდება ხშირი შესვლის იძულების გარეშე. ერთ token-ში ორივეს უსაფრთხოდ ვერ გექნებათ — ამიტომ ჰყოფთ დავალებას.
Authorization header-ში ყოველ API გამოძახებაზე. რადგან ის მუდმივად გადაიცემა, გაჟონვა სავარაუდოა; მისი ხანმოკლედ შენარჩუნება ნიშნავს, რომ მოპარული თითქმის მაშინვე იწურება.Login ──▶ access (15m) + refresh (30d)
ყოველი API გამოძახება ──▶ access-ის გაგზავნა
Access ვადაგასულია ──▶ refresh-ის გაგზავნა ──▶ ახალი access (+ როტირებული refresh)
| ერთი ხანგრძლივი access token | Access + refresh | |
|---|---|---|
| ექსპოზიცია | იგზავნება ყოველ მოთხოვნაზე, დიდხანს ცოცხლობს → დიდი ქურდობის ფანჯარა | Access ხანმოკლეა; refresh იშვიათად იგზავნება |
| გაუქმება | რთული (stateless JWT-ის გამოშვება ვერ გაუქმდება) | გააუქმეთ refresh token; access წუთებში კვდება |
| UX | ხშირი ხელახალი შესვლა, თუ მოკლეა | რჩება შესული ავტორიზაციის მონაცემების ხელახლა შეყვანის გარეშე |
| გაჟონვის აფეთქების რადიუსი | დიდი | მცირე (access სწრაფად იწურება) |
httpOnly cookie-ში, XSS-ის მიღწევის მიღმა.ეს არის სტანდარტული თანამედროვე ავთენტიფიკაციის დიზაინი და ინტერვიუერები ამას სვამენ იმის დასანახად, გესმით თუ არა რატომ, არა მხოლოდ როგორ. მთავარი ინსაითი არის კომპრომისი: უმდგომარეობობა და მოკლე ექსპოზიცია (access) გრძელი სესიებისა და გაუქმებადობის (refresh) წინააღმდეგ. მისი არასწორად გაკეთება — ხანგრძლივი access token, როტაციის გარეშე, localStorage-ში შენახული refresh — ერთ გაჟონილ token-ს ხანგრძლივ ანგარიშის კომპრომეტირებად აქცევს. გაყოფის დასახელება და ის, თუ რას გაძლევთ თითოეული token, სწორედ ისაა, რაც უსაფრთხოებაზე ორიენტირებულ ინჟინერს მოეთხოვება იცოდეს.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა