Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Arno Welzel <usenet@arnowelzel.de>
Newsgroups: de.comp.lang.javascript
Subject: Re: Authorization: Bearer in "normalem" GET Request
Date: Fri, 5 Aug 2022 10:46:40 +0200
Lines: 52
Message-ID: <jl43ngFnghqU1@mid.individual.net>
References: <slrntekhi4.57bk.hjp-usenet3@trintignant.hjp.at> <jkv9btFrfd6U1@mid.individual.net> <slrntepjid.9hvl.hjp-usenet3@trintignant.hjp.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net qy38zwOaXfuPcUIT9j6UJwy5GGV9UQYDtqZ6duQfEYmU3DLZNo
Cancel-Lock: sha1:bMwurKusMZrTtYXF8Yr0v+t+4EU=
Content-Language: de-DE
In-Reply-To: <slrntepjid.9hvl.hjp-usenet3@trintignant.hjp.at>
Xref: csiph.com de.comp.lang.javascript:5316

Peter J. Holzer, 2022-08-05 10:01:

> On 2022-08-03 12:52, Arno Welzel <usenet@arnowelzel.de> wrote:
>> Peter J. Holzer, 2022-08-03 11:56:
>>> Ich habe ein API, das Requests über ein Bearer Tokens authentifiziert.
>>> Das funktioniert wunderbar, solange Requests über JavaScript (im
>>> konkreten Fall mittels Axios) generiert und der Output wieder in
>>> JavaScript konsumiert wird.
>>>
>>> Nun möchte ich aber dem User einen Download-Link anbieten. Das wäre im
>>> einfachsten Fall einfach ein <a href="//api.example/whatever/123">...</a>
>>> oder man könnte window.location setzen. Aber der Browser weiß nichts von
>>> dem Bearer-Token und setzt daher den Authorization Header nicht.
>>>
>>> Gibt es eine Möglichkeit, den Authorization Header präemptiv zu setzen?
>>
>> Nein. Der muss schon explizit angefordert werden.
> 
> Naja, bei Basic Authentification fragt der Browser ja auch nicht
> jedesmal den User, wenn er ein 401 bekommt, sondern merkt sich die
> (Hostname, Realm, Username, Passwort)-Tupel. Das könnte er auch für
> Bearer Authentification machen, das Problem hier ist aber, dass der
> Input dafür vom Server kommt (ein Bearer-Token ist üblicherweise ein JWT
> oder sonst ein signierter Blob) und nicht vom User. Man bräuchte also
> die Möglichkeit, das programmatisch entweder präenptiv oder über einen
> Callback zu setzen.

Genau das meine ich ja - man kann den Authorization Header nicht senden,
ohne ihn vorher vom Server anzufordern.

[...]
> Der Code sieht jetzt übrigens so aus:
> 
>     axios.get(endpoint, options)
>         .then((res) => {
>             const blob = new Blob([res.data], {type: res.headers["content-type"]})
>             const url = window.URL.createObjectURL(blob);
>             const link = document.getElementById("download");
>             link.href = url;
>             link.click();
>         })

D.h. jeder Angreifer kann sich den Authorization Header einfach anhand
des frei zugänglichen Code in seinem Browser per Web Developer-Console
einfach abgreifen? Oder ist das Code, den nur Benutzer zu sehen
bekommen, die sich vorher schon anderweitig authentifizieren mussten?



-- 
Arno Welzel
https://arnowelzel.de