https://blog.yusukeikoma.com/ja/tags/security/Recent content in security on Ikoma's BlogHugoja-jpThu, 17 Sep 2026 09:49:13 +0900https://blog.yusukeikoma.com/ja/posts/ignoring-unknown-jwt-claims-only-removes-access/Thu, 17 Sep 2026 09:49:13 +0900https://blog.yusukeikoma.com/ja/posts/ignoring-unknown-jwt-claims-only-removes-access/JWT の仕様は、検証側が理解できないクレームは無視するよう定めています。権限を与えるクレームなら無害ですが、制限するクレームでは危険です。クライアントの種類ごとに持てる権限の上限を決める4つの設計を、小さな発行者と3種類の検証側で試し、僕が選ぶ設計を示します。https://blog.yusukeikoma.com/ja/posts/step-up-authentication-challenge-is-a-401/Tue, 15 Sep 2026 13:18:09 +0900https://blog.yusukeikoma.com/ja/posts/step-up-authentication-challenge-is-a-401/RFC 9470 は、API がクライアントに「このトークンは、弱すぎる、または古すぎるログインで取得されたものだ」と伝える方法を定めています。RFC を節ごとに読み、試作のサーバーとクライアントを作ると、仕様が決めているもの(401 のチャレンジと2つのパラメーター)と、実装側に残されているもの(同時に届くチャレンジ、ループ、キャッシュ)が分かります。https://blog.yusukeikoma.com/ja/posts/websocket-origin-check-is-not-authentication/Thu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/ja/posts/websocket-origin-check-is-not-authentication/WebSocket のハンドシェイクにある Origin ヘッダーは、ブラウザが付けるもので、それ以外のクライアントは好きな値を送れます。許可リストが守るのは、Cookie 認証のブラウザセッションが他のサイトから使われることで、接続してきた相手が誰かは証明しません。動くサーバー、実ブラウザでの攻撃、そこから導かれるハンドシェイクの規則を示します。https://blog.yusukeikoma.com/ja/posts/websocket-reauthentication-on-long-lived-connections/Fri, 21 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/ja/posts/websocket-reauthentication-on-long-lived-connections/101 レスポンスのあと、どのリクエストにも認証情報は載りません。サーバーが覚えているのは証拠ではなく判定結果だけです。1つのトークンをブラウザのハンドシェイクから追いかけ、ページから何が見えて何が見えないかを確かめたうえで、再接続・帯域内(in-band)・帯域外(out-of-band)の3つの更新方法を、動くサーバーとテストとヘッドレス Chrome の確認つきで比べます。https://blog.yusukeikoma.com/ja/posts/separate-authentication-and-authorization/Tue, 11 Aug 2026 17:14:04 +0900https://blog.yusukeikoma.com/ja/posts/separate-authentication-and-authorization/API の認証とロールベース認可を、主体・経路ごとの権限・人とマシンの認証情報に分けて設計する方法を説明します。