https://blog.yusukeikoma.com/ja/tags/authentication/Recent content in authentication on Ikoma's BlogHugoja-jpTue, 15 Sep 2026 13:18:09 +0900https://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/refresh-token-rotation-concurrent-requests/Sun, 30 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/リフレッシュトークンのローテーションは、使用済みトークンの再利用を盗難の警報として扱います。期限切れのアクセストークンで3つのリクエストを同時に送り、401ごとに更新するクライアントは、同じリフレッシュトークンを3回提示して、自分で警報を鳴らします。この記事では、素朴なクライアントをあえて壊し、single-flight と stale check で直します。そのうえで、サーバー側の猶予期間、リクエストの待機、先回り更新、送信者制約付きトークンを比べます。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 の認証とロールベース認可を、主体・経路ごとの権限・人とマシンの認証情報に分けて設計する方法を説明します。