Jaký je přesně rozdíl mezi následujícími dvěma hlavičkami:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr Všechny zdroje kterým jsem prošel, nastaví hodnotu hlavičky „Autorizace“ na „Nositel“ následovanou skutečným tokenem. Nedokázal jsem však pochopit jeho význam. Co když jednoduše vložím token do záhlaví Autorizace?
Komentáře
- Existují i jiné metody ověřování pomocí protokolu HTTP, například základní nebo výtah . Předpokládám, že je ' hezké je rozlišovat.
- Otázka se konkrétně týká ověřování na základě tokenu, které se obvykle provádí po základním ověření, aby uživatel nemusí ' při každé žádosti uvádět uživatelské jméno a heslo.
- Také jsem měl podobnou otázku. Chtěl jsem zvolit schéma pro implementaci tokenu s krátkou životností, které není plně kompatibilní s Oauth 2.0. Napadlo mě, jestli mohu použít Bearer nebo jakoukoli nestandardní hodnotu, aniž bych se dostal do potíží s interpretací proxy ' a serverů '. Nejbližší, kde jsem našel odpověď, bylo: stackoverflow.com/questions/7802116/… a stackoverflow.com/questions/8463809/…
- Vracejí servery obecně token stejnou cestou tj. " Autorizace: Nositel " odpovědi HTTP? Nebo je téměř vždy součástí těla odpovědi?
- Tato ověřovací stránka HTTP na MDN je pro diskusi velmi užitečná.
Odpověď
Vzor Authorization: <type> <credentials> byl představen W3C v HTTP 1.0 a od té doby se opakovaně používá na mnoha místech. Mnoho webových serverů podporuje více metod autorizace. V těchto případech není dostatečné odeslání pouze tokenu.
Weby, které používají formát
Authorization : Bearer cn389ncoiwuencr s největší pravděpodobností implementují OAuth 2.0 nosné tokeny . Autorizační rámec OAuth 2.0 stanoví řadu dalších požadavků, aby byla autorizace zabezpečena, například vyžadující použití HTTPS / TLS.
Pokud se integrujete se službou využívající OAuth 2.0, je dobré se seznámit s frameworkem, aby tok, který používáte, byl správně implementováno a vyhnout se zbytečným zranitelnostem. Online je k dispozici celá řada dobrých výukových programů.
Komentáře
- I ' Nejsem obeznámen s rozhraním MS Graph API, což by mohlo být podivínem jejich implementace.
- Na to jsem myslel. Vzhledem k vaší znalosti nosných tokenů a tokenů obecně můžete vidět jakékoli zabezpečení důsledky tím, že API přijímá token wi thout the Bearer keyword?
- Ve skutečnosti ne, ale souhlasím s jedním komentářem v této otázce – pokud se jejich implementace v tomto bodě liší, v čem je jiný? Jak již bylo řečeno, existuje řada implementací podobných OAuth, které se odchylují od RFC. Neznamená to automaticky, že jejich implementace jsou méně bezpečné.
Odpovědět
Dlouho před autorizací nositele, tato hlavička byla použita pro základní ověřování . Pro interoperabilitu se použití těchto záhlaví řídí normami W3C, takže i když čtete a zapisujete záhlaví, měli byste se jimi řídit. Nosič rozlišuje typ oprávnění, které používáte, takže je to důležité.
Odpověď
Token nosiče je nastaven v záhlaví Autorizace každého požadavku HTTP Inline Action a Nositel sám určuje typ ověřování.
Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens
Komentáře
- Tato odpověď je specifická pro vývojáře v Gmailu, nikoli pro všechny webové vývojáře. Akce ' ' je koncept Gmailu.