Care este exact diferența dintre următoarele două anteturi:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr Toate sursele prin care am trecut, setează valoarea antetului „Autorizare” ca „Purtător” urmat de simbolul propriu-zis. Cu toate acestea, nu am putut înțelege semnificația acestuia. Ce se întâmplă dacă aș pune pur și simplu simbolul în antetul de autorizare?
Comentarii
- Există alte metode de autentificare http, cum ar fi basic sau rezumat . Presupun că este ' plăcut să le puteți distinge.
- Întrebarea este specifică despre autentificarea bazată pe token, care se face de obicei după autentificarea de bază, astfel încât utilizatorul ' nu trebuie să furnizeze numele de utilizator și parola cu fiecare solicitare.
- Am avut și eu o întrebare similară. Am vrut să aleg o schemă pentru o implementare de simboluri de scurtă durată, care nu este pe deplin compatibilă cu Oauth 2.0. Mă întrebam dacă aș putea folosi Bearer sau orice valoare non-standard fără a avea probleme cu proxy-urile ' și cu serverele '. Cel mai aproape am găsit un răspuns: stackoverflow.com/questions/7802116/… și stackoverflow.com/questions/8463809/…
- Serverele returnează în general un token pe același traseu adică " Autorizare: purtător " al răspunsului HTTP? Sau face parte aproape întotdeauna din corpul de răspuns?
- Această pagină de autentificare HTTP din MDN este foarte utilă pentru discuție.
Răspuns
Modelul Authorization: <type> <credentials> a fost introdus de W3C în HTTP 1.0 și de atunci a fost reutilizat în multe locuri. Multe servere web acceptă mai multe metode de autorizare. În acele cazuri, trimiterea doar simbolului nu este „suficientă.
Site-urile care utilizează formatul
Authorization : Bearer cn389ncoiwuencr sunt cel mai probabil implementând OAuth 2.0 jetoane la purtător . OAuth 2.0 Authorization Framework stabilește o serie de alte cerințe pentru a menține securizarea autorizației, de exemplu, necesitând utilizarea HTTPS / TLS.
Dacă vă integrați cu un serviciu care utilizează OAuth 2.0, este o idee bună să vă familiarizați cu cadrul, astfel încât fluxul pe care îl utilizați să fie implementate corect și evitând vulnerabilitățile inutile. Există o serie de tutoriale bune disponibile online.
Comentarii
- I ' Nu sunt familiarizat cu API-ul MS Graph, ar putea fi o ciudățenie a implementării lor.
- La asta mă gândeam. Având în vedere cunoștințele dvs. despre jetoanele purtătorului și jetoanele în general, puteți vedea siguranță implicații prin faptul că API acceptă simbolul wi fără cuvântul cheie Bearer?
- Nu chiar, dar sunt de acord cu un comentariu în această întrebare – dacă implementarea lor diferă în acest sens, ce altceva este diferit? Acestea fiind spuse, există o serie de implementări de tip OAuth, care se abat de la RFC-uri. Totuși, nu înseamnă automat că implementările lor sunt mai puțin sigure.
Răspuns
Cu mult înainte de autorizarea purtătorului, acest antet a fost utilizat pentru autentificare de bază . Pentru interoperabilitate, utilizarea acestor anteturi este guvernată de normele W3C, așa că, chiar dacă citiți și scrieți antetul, ar trebui să le urmați. Purtătorul distinge tipul de autorizare pe care îl utilizați, deci este important.
Răspuns
Un jeton de purtător este setat în antetul de autorizare al fiecărei cereri HTTP de acțiune în linie, iar purtătorul însuși determină tipul de autentificare.
Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens
Comentarii
- Acest răspuns este specific dezvoltatorilor de Gmail, nu tuturor dezvoltatorilor web. O acțiune ' ' este o conceptul Gmail.