Mi a különbség a következő két fejléc között:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr Az összes forrás amin átestem, az “Engedélyezés” fejléc értékét “Bearer” -nek, majd a tényleges tokent állítja be. Ennek jelentőségét azonban nem sikerült megértenem. Mi lenne, ha egyszerűen betenném a tokent az Engedélyezés fejlécbe?
Megjegyzések
- A http-hitelesítésnek más módszerei is vannak, például basic vagy emésztés . Feltételezem, hogy ' jó, hogy meg tudjuk különböztetni őket.
- A kérdés kifejezetten a Token alapú hitelesítésről szól, amelyet általában az alap hitelesítés után végeznek, hogy a felhasználó nem ' nem kell minden felhasználáshoz megadnunk a felhasználónevet és a jelszót.
- Nekem is volt hasonló kérdésem. Egy rövid élettartamú token megvalósításhoz szerettem volna egy olyan rendszert választani, amely nem teljes mértékben megfelel az Oauth 2.0-nak. Kíváncsi voltam, hogy használhatom-e a Bearer vagy bármilyen nem szabványos értéket anélkül, hogy bajba kerülnék a proxyk ' és a ' szerverek értelmezésével. A válaszhoz legközelebb a következőt találtam: stackoverflow.com/questions/7802116/… és stackoverflow.com/questions/8463809/…
- A szerverek általában ugyanazon az útvonalon adnak vissza tokent azaz " Engedélyezés: A HTTP-válasz " átvitele? Vagy szinte mindig a válasz test része?
- Ez a HTTP-hitelesítési oldal az MDN-en nagyon hasznos a megbeszéléshez.
Válasz
A Authorization: <type> <credentials> mintát a W3C vezette be a HTTP 1.0 , és azóta sok helyen újra felhasználják. Számos webszerver támogatja az engedélyezés több módszerét. Ezekben az esetekben csak a token elküldése nem elegendő.
A
Authorization : Bearer cn389ncoiwuencr formátumot használó webhelyek valószínűleg az OAuth 2.0-t valósítják meg hordozó tokenek . Az OAuth 2.0 engedélyezési keretrendszer számos más követelményt is meghatároz az engedély biztonságának megőrzése érdekében, például HTTPS / TLS használatát követeli meg.
Ha egy olyan szolgáltatásba integrálódik, amely az OAuth 2.0-t használja, akkor érdemes megismernie a keretrendszert, hogy a használt folyamat megfelelően telepítve és elkerülve a felesleges sérülékenységeket. Számos jó oktatóanyag érhető el az interneten.
Megjegyzések
- I ' nem ismerem az MS Graph API-t, lehet, hogy furcsállja a megvalósításukat.
- Ez az, amire gondoltam. Tekintettel a Bearer Tokenek és általában a tokenek ismeretére, láthat-e bármilyen biztonságot következményekkel jár az a tény, hogy az API elfogadja a wi tokent a hordozó kulcsszóra?
- Nem igazán, de egyetértek a kérdés egy megjegyzésével – ha megvalósításuk ezen a ponton eltér, mi más a különbség? Ennek ellenére számos OAuth-szerű megvalósítás létezik, amelyek eltérnek az RFC-ktől. Ez azonban nem jelenti automatikusan azt, hogy megvalósításaik kevésbé biztonságosak.
Válasz
Jóval a jogosult engedélye előtt, ezt a fejlécet használták az alapvető hitelesítéshez . Az interoperabilitás érdekében ezeknek a fejléceknek a használatát a W3C normái szabályozzák, ezért még akkor is, ha elolvassa és írja a fejlécet, kövesse őket. A hordozó megkülönbözteti az Ön által használt engedély típusát, ezért fontos.
Válasz
A Bearer Token minden Inline Action HTTP kérés Authorization fejlécében van beállítva, és a Bearer maga határozza meg a hitelesítés típusát.
Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens
Megjegyzések
- Ez a válasz a gmail fejlesztőkre vonatkozik, nem minden webfejlesztőre. A ' művelet ' egy gmail koncepció.