SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか？ - IDトークン自体にも、個人の属性（氏名等）情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性：JSによるCookieへのアクセスを防ぐため - Secure属性：流出防止のため - SameSite=strict：CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効／無効状態の確認」や「検証に成功した場合の身元の保証（アクセストークンの発行等）」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお

PHPerKaigi 2024 • Day 1での登壇資料です。 https://phperkaigi.jp/2024/ https://fortee.jp/phperkaigi-2024/proposal/0d0f8507-0a53-46f6-bca6-23386d78f17f ※ Authorizationヘッダーを利用したBearerトークン等の活用については言及していません。

2023年11月27日、LINEヤフーは同社のシステムが不正アクセスを受け外部にユーザー情報などが流出したと公表しました。その後も調査が継続して進められたところ、2024年2月14日には最終の調査報告として社外のサービス（ファイル共有やSlackなど）に対しても影響が認められたと公表しました。さらに今回の調査を通じて別の委託先2社を通じた不正アクセス事案も確認されたと同日に公表しました。ここでは関連する情報をまとめます。 社内外システムへ不正アクセス LINEヤフーが主体として管理運用するシステム（社内システム）と社内コミュニケーションに利用していた社外サービスシステムに影響が及んでいた。11/27公表を事案A、2/14公表を事案Bとして、具体名称が上がっているシステムは以下の通り。*1 旧ヤフー社側とはシステム基盤が異なることから、ヤフー側の情報への影響はない。また公表時点では流出可能性

どうもお疲れ様です。MESIです。 これは私が駆け出しの新卒1年目の頃でしょうか。 ある社内のつよつよエンジニアからこう言われました。 「MESIよ。流行りのフレームワークの使い方を覚えるのではなく、土台を理解しなさい」 彼はそう言い残すと1冊の本を残し会社を去っていきました。 これ。 託された本を読んでみたものの当時の私には難しすぎました。 理解ができないのですが、何が理解できないのかがわからない。そんな状態でした。 毎日この本とにらめっこをしましたが、時間だけが過ぎていきました。 大学でコンピュータサイエンスを全く学んでいない状態で入社した当時の私には難しすぎたのです。 私は諦めずにOS関連の低レイヤーの本を読み出しました。そして以下のループにハマりました 本の内容が理解できない ↓ 本を理解するために別の本を読む ↓ 理解できないのでまた別の本を読む いきなり難しい本にチャレンジをし

Chromeのクッキー廃止へ。ブラウザをチェックしてみよう2024.01.13 21:00165,976 Thomas Germain - Gizmodo US ［原文］ （ 岩田リョウコ ） グッバイ、クッキー！ Googleが長年にわたって進めてきたクッキーの廃止計画が1月4日､実行に移されました。Chromeウェブブラウザを利用しているユーザーのうち1％、約3000万人に対してクッキーを無効化。そして今年の年末までに、すべてのChromeユーザーのクッキーがなくなるとのことです。すべてのクッキーではなく、廃止されるのは追跡をするサードパーティークッキーです。 クッキーの役目って？プライバシーを守りたい人たちにとって、インターネットの元凶とみなされているクッキー。ほとんどのウェブでクッキーは、テック企業がオンライン上での私たちの行動を追跡する方法となっていました。ターゲット広告や他の多

ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基本の流れであると意識しておきましょう。 パスキーやID連携の

概要 どうもukmashiです。本記事では、１部目に引き続き、FEとBEで認可の処理が二元化してしまうのをどうクリアするかの提案する記事です。 １部目を読んでない方は、ぜひ読んでいただけると幸いです。 フロントエンドの認可ついて（１） ReactやVueを始めとして、SPA、Next.js、Nuxt.jsに関する認可についてまとめます。 フロントエンドの認可ついて（２） ← 本記事 後半では、FEとBEで認可の処理が二元化してしまうのをどうクリアするかの提案です。 フロントエンドの認可ついて（３） ２での提案を具体的にReactのコードとして落とし込みました なお、本記事ではサンプルコードとしてReactを使用します。 BEとFEの責務に関して １部の最後でもお話ししましたが、BE、FEそれぞれの責務について再度まとめます。 BEはデータ操作に関する責任を持つ FEは表示制御に関する責任を

ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April

2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。

決済といえば、NFC決済ですよね！そうですよね！？ これは Kyash Advent Calendar 2023 の2日目の記事です。 こんにちは。Kyashでプロダクトマネージャーをやってます、箭内と言います。 2023年も年末ですね。みなさまこの激動の年をどうお過ごしでしたでしょうか？ 1年の中でも、11月と12月は日本においては最も決済される時期になっていて、各カード会社の取引金額と取引件数は、毎年この2ヶ月間がピークになります(下図参照)。特に11月の最終週の土日は、「1年のうちで最も決済される日」になることが多いです。ブラックフライデーなんていうイベントが最近は賑わっていましたし、クリスマスプレゼントの購入、大晦日や正月の買い出し、年末年始の旅行、帰省など、イベント目白押しです。個人的にも世の中がワイワイしている感じで好きなんですよね〜。寒いんですけど。 日本クレジットカード協会

ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023　の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ

安全なウェブサイトの作り方を読んだので、理解した内容を自分なりにまとめておきます。資料 上記は3章構成になっていてそれぞれ長めの内容なので、ここでは3章の『失敗例』について、Ruby on Rails ではどうするかについてをまとめます。 SQL インジェクション OS コマンドインジェクション パス名パラメータの未チェック例（ディレクトリトラバーサル） 不適切なセッション管理例（セッション ID の推測） クロスサイト・スクリプティングの例（エスケープ処理） CSRFの例 HTTP ヘッダ・インジェクションの例 メールヘッダ・インジェクションの例 参考 SQL インジェクション 参考資料内の SQL インジェクション例を見て、Ruby on Rails ではどのように対策できるかを確認しました。 例えば、下記ような $uid, $pass をユーザ入力とし、SQL 文を動的に生成する場合

2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらのスライドの内容は以下の本の抜粋になります。デモの内容、このスライドでは触れていないことについてご興味ある場合は以下の本をご参照ください。 https://authya.booth.pm/items/1296585 https://authya.booth.pm/items/1550861 本発表で扱っていないセキュリティに関しては以下の本がおすすめです。 https://authya.booth.pm/items/1877818 本の評判 https://togetter.com/li/1477483

www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている（ご存じの方は彼にご一報を）。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80％、いやもしかしたら90％をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく

SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう

不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認