Jaka jest dokładnie różnica między następującymi dwoma nagłówkami:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr Wszystkie źródła przez który przeszedłem, ustawia wartość nagłówka „Authorization” na „Bearer”, po której następuje rzeczywisty token. Jednak nie byłem w stanie zrozumieć, jakie to ma znaczenie. A co jeśli po prostu wstawię token w nagłówku Authorization?
Komentarze
- Istnieją inne metody uwierzytelniania http, takie jak basic lub podsumowanie . Przypuszczam, że ' miło jest móc je rozróżnić.
- Pytanie dotyczy konkretnie uwierzytelniania opartego na tokenach, które jest zwykle wykonywane po uwierzytelnieniu podstawowym, nie ' nie muszę podawać nazwy użytkownika i hasła przy każdym żądaniu.
- Ja też miałem podobne pytanie. Chciałem wybrać schemat krótkotrwałej implementacji tokena, który nie jest w pełni zgodny z Oauth 2.0. Zastanawiałem się, czy mógłbym użyć Bearer lub dowolnej niestandardowej wartości bez kłopotów z interpretacją serwerów proxy ' i serwerów '. Najbliżej znalezienia odpowiedzi były: stackoverflow.com/questions/7802116/… i stackoverflow.com/questions/8463809/…
- Czy serwery zazwyczaj zwracają token tą samą drogą tj. " Autoryzacja: Nośnik " odpowiedzi HTTP? A może prawie zawsze jest częścią treści odpowiedzi?
- Ta strona uwierzytelniania HTTP w MDN jest bardzo przydatna w dyskusji.
Odpowiedź
Wzorzec Authorization: <type> <credentials> został wprowadzony przez W3C w HTTP 1.0 i od tego czasu był ponownie używany w wielu miejscach. Wiele serwerów WWW obsługuje wiele metod autoryzacji. W takich przypadkach wysłanie samego tokena nie jest wystarczające.
Witryny korzystające z formatu
Authorization : Bearer cn389ncoiwuencr najprawdopodobniej implementują OAuth 2.0 tokeny na okaziciela . Struktura autoryzacji OAuth 2.0 określa szereg innych wymagań w celu zapewnienia bezpieczeństwa autoryzacji, na przykład wymaganie użycia HTTPS / TLS.
Jeśli przeprowadzasz integrację z usługą, która korzysta z protokołu OAuth 2.0, dobrze jest zapoznać się ze strukturą, aby przepływ, którego używasz, był poprawnie zaimplementowany i unikając niepotrzebnych luk w zabezpieczeniach. W Internecie dostępnych jest wiele dobrych samouczków.
Komentarze
- I ' Nie jestem zaznajomiony z MS Graph API, może to być dziwactwo ich implementacji.
- Tak właśnie myślałem. Biorąc pod uwagę twoją wiedzę na temat tokenów okaziciela i ogólnie tokenów, czy widzisz jakieś zabezpieczenia konsekwencje wynikające z faktu, że API akceptuje token wi o słowie kluczowym Bearer?
- Niezupełnie, ale zgadzam się z jednym komentarzem w tym pytaniu – jeśli ich implementacja różni się w tym punkcie, co jeszcze jest innego? Mając to na uwadze, istnieje wiele implementacji podobnych do OAuth, które różnią się od specyfikacji RFC. Nie oznacza to jednak automatycznie, że ich implementacje są mniej bezpieczne.
Odpowiedź
Na długo przed autoryzacją okaziciela, ten nagłówek był używany do podstawowego uwierzytelniania . Aby zapewnić interoperacyjność, użycie tych nagłówków jest regulowane przez normy W3C, więc nawet jeśli czytasz i piszesz nagłówek, powinieneś postępować zgodnie z nimi. Nośnik rozróżnia typ Autoryzacji, którego używasz, więc jest to ważne.
Odpowiedź
Token okaziciela jest ustawiany w nagłówku autoryzacji każdego żądania HTTP w akcji wbudowanej, a sam nośnik określa typ uwierzytelniania.
Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens
Komentarze
- Ta odpowiedź jest specyficzna dla programistów Gmaila, a nie dla wszystkich twórców stron internetowych. ' akcja ' to koncepcja gmaila.