5.3. Device Trustworthiness (设备可信度)
🇬🇧 English
Unlike other native application OAuth 2.0 flows, the device requesting the authorization is not the same as the device from which the user grants access. Thus, signals from the approving user's session and device are not always relevant to the trustworthiness of the client device.
Note that if an authorization server used with this flow is malicious, then it could perform a man-in-the-middle attack on the backchannel flow to another authorization server. In this scenario, the man-in-the-middle is not completely hidden from sight, as the end user would end up on the authorization page of the wrong service, giving them an opportunity to notice that the URL in the browser's address bar is wrong. For this to be possible, the device manufacturer must either be the attacker and shipping a device intended to perform the man-in-the-middle attack, or be using an authorization server that is controlled by an attacker, possibly because the attacker compromised the authorization server used by the device. In part, the person purchasing the device is counting on the manufacturer and its business partners to be trustworthy.
🇨🇳 中文
与其他原生应用 OAuth 2.0 流程不同,请求授权的设备与用户授予访问权限的设备不同。因此,来自批准用户的会话和设备的信号并不总是与客户端设备的可信度相关。
请注意,如果与此流程一起使用的授权服务器是恶意的,那么它可能会对到另一个授权服务器的后通道流程执行中间人攻击。在这种情况下,中间人并非完全隐藏,因为最终用户会最终到达错误服务的授权页面,这给了他们一个机会注意到浏览器地址栏中的 URL 是错误的。为了使这成为可能,设备制造商必须是攻击者并运送旨在执行中间人攻击的设备,或者使用由攻击者控制的授权服务器,可能是因为攻击者破坏了设备使用的授权服务器。在某种程度上,购买设备的人指望制造商及其业务合作伙伴是值得信赖的。
🇯🇵 日本語
他のネイティブアプリケーション OAuth 2.0 フローとは異なり、認可を要求するデバイスは、ユーザーがアクセスを許可するデバイスと同じではありません。したがって、承認するユーザーのセッションとデバイスからのシグナルは、常にクライアントデバイスの信頼性に関連しているわけではありません。
このフローで使用される認可サーバーが悪意のあるものである場合、別の認可サーバーへのバックチャネルフローに対して中間者攻撃を実行できることに注意してください。このシナリオでは、中間者は完全に隠されているわけではなく、エンドユーザーは間違ったサービスの認可ページにたどり着くため、ブラウザのアドレスバーの URL が間違っていることに気付く機会が与えられます。これが可能になるには、デバイスメーカーが攻撃者であり、中間者攻撃を実行することを意図したデバイスを出荷しているか、攻撃者によって制御された認可サーバーを使用している必要があります。おそらく、攻撃者がデバイスで使用される認可サーバーを侵害したためです。ある程度、デバイスを購入する人は、メーカーとそのビジネスパートナーが信頼できることを期待しています。
🇫🇷 Français
Contrairement à d'autres flux OAuth 2.0 d'application native, l'appareil demandant l'autorisation n'est pas le même que l'appareil à partir duquel l'utilisateur accorde l'accès. Ainsi, les signaux de la session de l'utilisateur approbateur et de l'appareil ne sont pas toujours pertinents pour la fiabilité de l'appareil client.
Notez que si un serveur d'autorisation utilisé avec ce flux est malveillant, il pourrait alors effectuer une attaque de l'homme du milieu sur le flux de canal arrière vers un autre serveur d'autorisation. Dans ce scénario, l'homme du milieu n'est pas complètement caché de la vue, car l'utilisateur final se retrouverait sur la page d'autorisation du mauvais service, lui donnant l'occasion de remarquer que l'URL dans la barre d'adresse du navigateur est incorrecte. Pour que cela soit possible, le fabricant de l'appareil doit soit être l'attaquant et expédier un appareil destiné à effectuer l'attaque de l'homme du milieu, soit utiliser un serveur d'autorisation contrôlé par un attaquant, peut-être parce que l'attaquant a compromis le serveur d'autorisation utilisé par l'appareil. En partie, la personne qui achète l'appareil compte sur le fabricant et ses partenaires commerciaux pour être dignes de confiance.
🇩🇪 Deutsch
Im Gegensatz zu anderen nativen Anwendungs-OAuth 2.0-Abläufen ist das Gerät, das die Autorisierung anfordert, nicht dasselbe wie das Gerät, von dem aus der Benutzer Zugriff gewährt. Daher sind Signale aus der Sitzung und dem Gerät des genehmigenden Benutzers nicht immer für die Vertrauenswürdigkeit des Client-Geräts relevant.
Beachten Sie, dass wenn ein mit diesem Ablauf verwendeter Autorisierungsserver bösartig ist, er einen Man-in-the-Middle-Angriff auf den Backchannel-Ablauf zu einem anderen Autorisierungsserver durchführen könnte. In diesem Szenario ist der Man-in-the-Middle nicht vollständig verborgen, da der Endbenutzer auf der Autorisierungsseite des falschen Dienstes landen würde, was ihm die Gelegenheit gibt zu bemerken, dass die URL in der Adressleiste des Browsers falsch ist. Damit dies möglich ist, muss der Gerätehersteller entweder der Angreifer sein und ein Gerät versenden, das dazu bestimmt ist, den Man-in-the-Middle-Angriff durchzuführen, oder einen Autorisierungsserver verwenden, der von einem Angreifer kontrolliert wird, möglicherweise weil der Angreifer den vom Gerät verwendeten Autorisierungsserver kompromittiert hat. Teilweise verlässt sich die Person, die das Gerät kauft, darauf, dass der Hersteller und seine Geschäftspartner vertrauenswürdig sind.
🇮🇹 Italiano
A differenza di altri flussi OAuth 2.0 di applicazioni native, il dispositivo che richiede l'autorizzazione non è lo stesso dispositivo da cui l'utente concede l'accesso. Pertanto, i segnali dalla sessione dell'utente approvante e dal dispositivo non sono sempre rilevanti per l'affidabilità del dispositivo client.
Si noti che se un server di autorizzazione utilizzato con questo flusso è malevolo, potrebbe eseguire un attacco man-in-the-middle sul flusso del canale posteriore verso un altro server di autorizzazione. In questo scenario, il man-in-the-middle non è completamente nascosto alla vista, poiché l'utente finale finirebbe sulla pagina di autorizzazione del servizio sbagliato, dandogli l'opportunità di notare che l'URL nella barra degli indirizzi del browser è sbagliato. Perché ciò sia possibile, il produttore del dispositivo deve essere l'aggressore e spedire un dispositivo destinato a eseguire l'attacco man-in-the-middle, o utilizzare un server di autorizzazione controllato da un aggressore, possibilmente perché l'aggressore ha compromesso il server di autorizzazione utilizzato dal dispositivo. In parte, la persona che acquista il dispositivo conta sul fatto che il produttore e i suoi partner commerciali siano affidabili.