Hvad er præcis forskellen mellem følgende to overskrifter:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr Alle kilder som jeg har gennemgået, indstiller værdien af “Authorization” -overskrift som “Bearer” efterfulgt af det aktuelle token. Imidlertid har jeg ikke været i stand til at forstå betydningen af det. Hvad hvis jeg blot sætter tokenet i autorisationsoverskriften?
Kommentarer
- Der er andre metoder til http-godkendelse, som basic eller fordøjelse . Jeg antager, at det ' er rart at kunne skelne mellem dem.
- Spørgsmålet drejer sig specifikt om tokenbaseret godkendelse, som normalt udføres efter grundlæggende godkendelse, så brugeren behøver ' ikke at angive brugernavnet og adgangskoden med hver anmodning.
- Jeg havde også et lignende spørgsmål. Jeg ønskede at vælge en ordning til en kortvarig tokenimplementering, som ikke er fuldt ud Oauth 2.0-kompatibel. Jeg spekulerede på, om jeg kunne bruge bærer eller nogen ikke-standardværdi uden at komme i problemer med proxies ' og servere ' fortolkning. Det tætteste jeg kom på at finde et svar var: stackoverflow.com/questions/7802116/… og stackoverflow.com/questions/8463809/…
- Returnerer servere generelt et token via den samme rute dvs. " Autorisation: Bærer " af HTTP-svaret? Eller er det næsten altid en del af responsorganet?
- Denne HTTP-godkendelsesside på MDN er meget nyttig til diskussionen.
Svar
Authorization: <type> <credentials> mønster blev introduceret af W3C i HTTP 1.0 og er blevet genbrugt mange steder siden. Mange webservere understøtter flere metoder til godkendelse. I disse tilfælde er det bare ikke nok at sende tokenet.
Websteder, der bruger
Authorization : Bearer cn389ncoiwuencr -formatet implementerer sandsynligvis OAuth 2.0 bærertokens . OAuth 2.0 Authorization Framework sætter en række andre krav for at sikre godkendelsen, for eksempel at kræve brug af HTTPS / TLS.
Hvis du integrerer med en tjeneste, der bruger OAuth 2.0, er det en god ide at blive fortrolig med rammen, så det flow, du bruger, er implementeret korrekt og undgå unødvendige sårbarheder. Der er en række gode tutorials tilgængelige online.
Kommentarer
- I ' Jeg er ikke fortrolig med MS Graph API, kan være et særpræg for deres implementering.
- Det var det, jeg tænkte. I betragtning af din viden om bærertokens og tokens generelt, kan du se nogen sikkerhed implikationer af det faktum, at APIen accepterer token wi om bærer-nøgleordet?
- Ikke rigtig, men jeg er enig med en kommentar i det spørgsmål – hvis deres implementering adskiller sig på dette punkt, hvad er der andet? Når det er sagt, er der en række OAuth-lignende implementeringer derude, der afviger fra RFCerne. Det betyder dog ikke automatisk, at deres implementeringer er mindre sikre.
Svar
Længe før indehaveren godkendes, denne overskrift blev brugt til Grundlæggende godkendelse . For interoperabilitet styres brugen af disse overskrifter af W3C-normer, så selvom du læser og skriver overskriften, skal du følge dem. Bearer skelner mellem den type autorisation, du bruger, så det er vigtigt.
Svar
En bærertoken er indstillet i autorisationsoverskriften for hver Inline Action HTTP-anmodning, og bæreren selv bestemmer typen af godkendelse.
Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens
Kommentarer
- Dette svar er specifikt for gmail-udviklere, ikke for alle webudviklere. En ' handling ' er en gmail-koncept.