Wat is precies het verschil tussen de volgende twee headers:
Authorization : Bearer cn389ncoiwuencr vs Authorization : cn389ncoiwuencr Alle bronnen die ik heb doorlopen, stelt de waarde van de “Autorisatie” header in op “Bearer” gevolgd door het eigenlijke token. Ik heb de betekenis ervan echter niet kunnen begrijpen. Wat moet ik doen als ik het token gewoon in de autorisatie-header plaats?
Reacties
- Er zijn andere methoden voor http-authenticatie, zoals basic of samenvatting . Ik neem aan dat het ' leuk is om ze te kunnen onderscheiden.
- De vraag gaat specifiek over op tokens gebaseerde authenticatie, die meestal wordt gedaan na basisauthenticatie, zodat de gebruiker hoeft niet ' de gebruikersnaam en het wachtwoord bij elk verzoek op te geven.
- Ik had ook een soortgelijke vraag. Ik wilde een schema kiezen voor een kortstondige tokenimplementatie, die niet volledig compatibel is met Oauth 2.0. Ik vroeg me af of ik Bearer of een niet-standaard waarde zou kunnen gebruiken zonder problemen te krijgen met proxys ' en servers ' interpretatie. Het dichtst bij het vinden van een antwoord was: stackoverflow.com/questions/7802116/… en stackoverflow.com/questions/8463809/…
- Retourneren servers over het algemeen een token via dezelfde route dwz " Autorisatie: drager " van het HTTP-antwoord? Of maakt het bijna altijd deel uit van de responsbody?
- Deze HTTP-authenticatiepagina op MDN is erg handig voor de discussie.
Antwoord
Het Authorization: <type> <credentials> -patroon werd door de W3C geïntroduceerd in HTTP 1.0 , en is sindsdien op veel plaatsen hergebruikt. Veel webservers ondersteunen meerdere autorisatiemethoden. In die gevallen is het verzenden van alleen het token niet voldoende.
Sites die het
Authorization : Bearer cn389ncoiwuencr -formaat gebruiken, implementeren hoogstwaarschijnlijk OAuth 2.0 bearer-tokens . Het OAuth 2.0 Authorization Framework stelt een aantal andere vereisten om autorisatie veilig te houden, bijvoorbeeld het gebruik van HTTPS / TLS vereist.
Als u “opnieuw integreert met een service die OAuth 2.0 gebruikt, is het een goed idee om vertrouwd te raken met het framework, zodat de stroom die u gebruikt, correct geïmplementeerd en onnodige kwetsbaarheden worden vermeden. Er zijn een aantal goede tutorials online beschikbaar.
Reacties
- I ' Ik ben niet bekend met de MS Graph API, misschien een eigenaardigheid van de implementatie ervan.
- Dat is wat ik dacht. Gezien uw kennis van Bearer Tokens en tokens in het algemeen, kunt u enige beveiliging zien implicaties door het feit dat de API het token wi accepteert het Bearer-trefwoord?
- Niet echt, maar ik ben het eens met een opmerking in die vraag – als hun implementatie op dit punt verschilt, wat is er dan anders? Dat gezegd hebbende, er zijn een aantal OAuth-achtige implementaties die afwijken van de RFCs. Het betekent echter niet automatisch dat hun implementaties minder veilig zijn.
Answer
Lang voordat de drager toestemming heeft gegeven, deze header werd gebruikt voor Basisverificatie . Voor interoperabiliteit wordt het gebruik van deze headers beheerst door W3C-normen, dus zelfs als je de header leest en schrijft, zou je ze moeten volgen. Bearer onderscheidt het type autorisatie dat je gebruikt, dus het is belangrijk.
Answer
Een Bearer Token wordt ingesteld in de Authorization-header van elke Inline Action HTTP Request en Bearer bepaalt zelf het type authenticatie.
Ref https://developers.google.com/gmail/markup/actions/verifying-bearer-tokens
Opmerkingen
- Dit antwoord is specifiek voor Gmail-ontwikkelaars, niet voor alle webontwikkelaars. Een ' -actie ' is een Gmail-concept.