JWT დეკოდერი

რას აკეთებს JWT დეკოდერი სინამდვილეში

JSON Web Token (JWT) გამოიყურება როგორც გრძელი, გაუმჭვირვალე შემთხვევითი სიმბოლოების სტრიქონი, მაგრამ ის არც დაშიფრულია და არც საიდუმლო შიფრია. ეს არის კომპაქტური, URL-უსაფრთხო კონტეინერი, რომელიც სტრუქტურულ მონაცემებს ორ მხარეს შორის ატარებს. ჩასვით ტოკენი ზემოთ მდებარე დეკოდერში და ის სტრიქონს დაშლის და გაჩვენებთ ნამდვილ JSON-ს შიგნით — მეტამონაცემებს, „claims"-ებს, ვისთვისაა ტოკენი განკუთვნილი და როდის იწურება ის. ყველაფერი პირდაპირ თქვენს ბრაუზერში ხდება. ტოკენი არასდროს იტვირთება, არ ილოგება და არ იგზავნება არსად, რაც დიდი მნიშვნელობისაა მაშინ, როცა ის, რასაც ათვალიერებთ, ცოცხალი სესიის ავტორიზაციის საშუალებაა.

სამი ნაწილი, ორი წერტილი

ყოველი კარგად ფორმირებული JWT სამი Base64url-ად კოდირებული სტრიქონია, წერტილებით შეერთებული: header.payload.signature. სწორედ ეს ცალკე წერტილის სიმბოლოა ის, რითაც პარსერები ხვდებიან, სად მთავრდება ერთი სექცია და იწყება მომდევნო, და სწორედ ამიტომ იუარყოფა ტოკენი, თუ წერტილების არასწორი რაოდენობაა, სანამ საერთოდ რაიმეს წაკითხვას დაიწყებენ.

სათაური პატარა JSON ობიექტია, რომელიც თავად ტოკენს აღწერს. ის თითქმის ყოველთვის შეიცავს typ-ს (ტიპი, ჩვეულებრივ JWT) და alg-ს — ხელმომწერ ალგორითმს, როგორიცაა HS256 (HMAC SHA-256-ით) ან RS256 (RSA SHA-256-ით). სათაური ვერიფიკატორს ზუსტად ეუბნება, როგორ შეიქმნა ხელმოწერა.

დატვირთვა ის ნაწილია, რომელსაც ხალხის უმეტესობა ითვალისწინებს. ეს კიდევ ერთი JSON ობიექტია, რომელიც claims-ს, ანუ მოთხოვნებს — განცხადებებს მომხმარებელსა და ტოკენზე — ატარებს. სპეციფიკაცია claims-ს რეგისტრირებულ (სტანდარტული, დაცული სახელები), საჯარო და კერძო (თქვენი აპლიკაციისთვის გამოგონილი, ინდივიდუალური სახელები) ჯგუფებად ყოფს. სწორედ დატვირთვის დეკოდირება ავლენს, ვინ არის ავტორიზებული, რა როლი აქვს და როდის იწურება მისი სესია.

ხელმოწერა კრიპტოგრაფიული ბეჭედია. ის გამოითვლება დაკოდირებული სათაურისა და დატვირთვის საფუძველზე, სათაურში მითითებული ალგორითმისა და საიდუმლო ან პირადი გასაღების გამოყენებით. რადგან ის ორივე დანარჩენ სექციას მოიცავს, ნებისმიერი ცვლილება სათაურში ან დატვირთვაში — თუნდაც ერთი სიმბოლო — მას ბათილად აქცევს.

claims-ები, რომლებსაც ყველაზე ხშირად ნახავთ

რეგისტრირებული claims-ები მოკლე, სამასოიანი სახელებია, RFC 7519-ით განსაზღვრული, რომ სხვადასხვა სისტემას ურთიერთგაგება ჰქონდეს. ერთი-ორი მათგანი თითქმის ყველგან გამოჩნდება:

• iss — issuer, გამომცემელი: ვინ შექმნა ტოკენი (თქვენი ავთენტიფიკაციის სერვერი ან საიდენტიფიკაციო პროვაიდერი).
• sub — subject, სუბიექტი: ვისზეა ტოკენი, ჩვეულებრივ სტაბილური მომხმარებლის ID.
• aud — audience, აუდიტორია: ვისთვისაა ტოკენი განკუთვნილი. API-მ უნდა უარყოს ტოკენი, რომლის აუდიტორია ის თავად არ არის.
• exp — expiration time, ვადის გასვლის დრო: Unix დროის შტამპი, რომლის შემდეგაც ტოკენი აღარ უნდა იქნას მიღებული.
• iat — issued at, გაცემის დრო: Unix დროის შტამპი, როცა ტოკენი შეიქმნა.

ასევე შეიძლება შეხვდეთ nbf-ს (not before, ადრე არ მოქმედებს) და jti-ს (უნიკალური ტოკენის ID). დროის შტამპები UTC-ში, 1970 წლიდან წამებში აითვლება, სწორედ ამიტომ გზოგავს დეკოდერი, რომელიც მათ ადამიანისთვის წაკითხვად თარიღებად აღბეჭდავს, გონებრივი არითმეტიკის დროს, როცა ამოწმებთ, ტოკენს უკვე ვადა ხომ არ გაუვიდა.

დეკოდირება არ არის ვერიფიკაცია — სწორედ აქ ბორტავენ ხოლმე

ეს განსხვავება JWT-ის შესახებ ერთადერთი ყველაზე მნიშვნელოვანი გასაგები საკითხია. დეკოდირება ნიშნავს შიგთავსის წაკითხვას: ის გასაღებს არ საჭიროებს, და ტოკენის ნებისმიერ მფლობელს შეუძლია მისი გაკეთება, რადგან Base64url არის კოდირება და არა დაშიფვრა. ვერიფიკაცია ნიშნავს დამტკიცებას, რომ ტოკენი ავთენტურია და ხელუხლებელი — ხელახლა გამოთვლის ხელმოწერას სწორი საიდუმლო ან საჯარო გასაღებით და ადასტურებს, ემთხვევა თუ არა ის.

ეს ხელსაწყო დეკოდირებას აკეთებს. ის გაჩვენებთ, რას ამბობს ტოკენი, და არა იმას, ტოკენი სანდოა თუ არა. ტოკენი შეიძლება გაყალბებული, ვადაგასული ან განმეორებით გამოყენებული იყოს და მაინც სრულიად სუფთა JSON-ად დეკოდირდეს. ავტორიზაციის გადაწყვეტილება არასდროს მიიღოთ მხოლოდ დეკოდირებული claims-ების საფუძველზე. წარმოებაში ხელმოწერა სერვერის მხარეს უნდა გადამოწმდეს, exp უნდა შემოწმდეს, და iss და aud უნდა დაემთხვას თქვენს მოლოდინს — გამოცდილი ბიბლიოთეკის გამოყენებით, არასდროს ხელით შედარებული სტრიქონებით.

დატვირთვა სეიფი არ არის

რადგან დატვირთვა მხოლოდ Base64url-ითაა კოდირებული, ის ტოკენის ნებისმიერი ჩამჭერისთვის წაკითხვადია. ყველაფერს მასში საჯაროდ განიხილეთ. ნუ ჩადებთ პაროლებს, სრულ საკრედიტო ბარათის ნომრებს, საიდუმლო გასაღებებს ან სხვა მგრძნობიარე პირად მონაცემებს JWT claims-ებში — თუ თქვენ ამის დეკოდირება ერთი დაწკაპუნებით შეგიძლიათ, ეს ასევე შეუძლია ნებისმიერს, ვინც ასლს მიიღებს. ხელმოწერა იცავს შეცვლისგან, მაგრამ არასდროს — წაკითხვისგან. თუ ნამდვილად გჭირდებათ დატვირთვის შიგთავსის დამალვა, ეს JWE-ს (დაშიფრული ტოკენების) საქმეა, სრულიად სხვა სპეციფიკაცია.

კონფიდენციალურობა და დაკავშირებული ხელსაწყოები

ტოკენის შემოწმება მგრძნობიარე მოქმედებაა, ამიტომ ეს დეკოდერი მთლიანად კლიენტის მხარეს მუშაობს — გარჩევა უბრალო JavaScript-ია თქვენს ჩანართში, და არაფერი ტოვებს თქვენს მოწყობილობას. სესიის ტოკენის სერვერზე დაფუძნებულ ხელსაწყოში ჩასმა ცოცხალი ავტორიზაციის საშუალების მესამე მხარისთვის გადაცემას ნიშნავს, რასაც ზუსტად უნდა გაერიდოთ. საბაზისო კოდირებისთვის იხილეთ ჩვენი Base64 ხელსაწყო, და გაეცანით ჩვენს დანარჩენ დეველოპერულ ხელსაწყოებს სხვა მოწყობილობაზე მომუშავე უტილიტებისთვის.

ხშირად დასმული კითხვები