Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
なぜ認証認可エンジニアはデジタルアイデンティティという言葉を使うのか
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
freee
PRO
October 20, 2026
Technology
57
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
なぜ認証認可エンジニアはデジタルアイデンティティという言葉を使うのか
freee 技術の日 2026のセッション資料です。
freee
PRO
October 20, 2026
More Decks by freee
See All by freee
dbt platform導入後の今
freee
PRO
0
280
データマネジメント × 法務で作りあげる、 freeeの新しいデータガバナンスへの軌跡
freee
PRO
3
740
freeeに点在する案件・プロジェクトを統合するための案件マスタ開発
freee
PRO
1
110
freeeにおけるSoftware Factory
freee
PRO
11
6.7k
freeeにおける AI を用いた ブラウザ動作確認の自動化の取り組み
freee
PRO
0
290
AIから最も使われやすいfreeeへ
freee
PRO
0
100
認知負荷との戦い〜 freee AIアシスタントの誕生からハーネス改善まで 〜
freee
PRO
0
150
脱SaaS脳 キャリア25年目の挑戦
freee
PRO
0
71
攻めと守りを両立するデータ基盤 〜中央集権型からデータメッシュへの道のり〜
freee
PRO
0
81
Other Decks in Technology
See All in Technology
Claude Codeで作ったアプリを安全に公開する/Built with Claude Japan 2026
yoshidashingo
0
170
試験勉強はGrokBotでやれ
maigo999
0
110
IoTとは〜? 数字で見るSORACOM UG【SORACOM UG Explorer 2026】
soracom
PRO
0
190
Consistency for mere mortals - A gentle guide to consistency
ufried
0
120
攻撃 3 時間 vs 復旧 10 時間。アクセスキー流出の非対称性を体感するために CTF を作った話
kazzpapa3
1
150
Content Mapper APIの応用例~CSS Modules、言語ファイル~
uhyo
2
610
続・ソフトウェアアーキテクトのための意思決定術: Decision Readiness, Revisited — When AI Changes the Economics of Software Architecture
snoozer05
PRO
9
2.6k
現場を動かすAIエージェント#2_製造業現場でのAI活用から見た、ハマる罠と実践知
kintotechdev
2
180
バックオフィスに染み出すTypeScript ── clasp で安全に仕組みを作る
nealle
1
180
Autonomous AI Lakehouse - Live AI Hubから始めるセキュアなAIデータ活用 -
oracle4engineer
PRO
3
190
Kiro Crew の Bot (続く役目を任せる窓口) | 目指せ Kiro マスター 12
inariku
PRO
1
280
HQ駆動開発で最高のAI-Contextを作ろう
sansantech
PRO
1
100
Featured
See All Featured
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
1k
エンジニアに許された特別な時間の終わり
watany
109
250k
Making the Leap to Tech Lead
cromwellryan
135
10k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.7k
A Modern Web Designer's Workflow
chriscoyier
699
190k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.4k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
550
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.7k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
1.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
7k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
Transcript
なぜ認証認可エンジニアはデジタルア イデンティティという⾔葉を使うのか hyudai 2026年10⽉3⽇
IAMエンジニア 早坂 悠大(hyudai) 2023年入社 2025年7月より認証・認可の領域に興 味を持ち異動 現在はOpenIdFoundation-japan 人材育成WGに参加
出発点:「仕様は分かるのに、何も改善案が浮かばない」 • チーム異動前、主要な仕様は勉強していました ◦ OAuth 2.0 / OIDC の認可フローとトークン検証 ◦
Passkey(WebAuthn)の公開鍵暗号による認証構造 • しかし、 次に何を学べばいいのかが浮かばない状態でした ◦ OAuth2.0のプロトコルやPasskeyのプロトコルを読み込むことでIdエ ンジニアとしての先が⾒えなかった ▪ 果たしてこれだけでいいのか...? ◦ 技術を独⽴した「点」でしか捉えていなかったからです
ケーススタディ:Passkeyを「導⼊する」と「使いこなす」の違い • 【点での捉え⽅】単に認証⼿段を追加しただけ ◦ 「Passkeyはフィッシングに強く安全」と導⼊ ◦ 結果: 攻撃者はPasskeyを無視し、従来通りの弱いパスワード側を狙 うだけ(全体としては安全になっていない) •
【線での捉え⽅】パスキーで安全にする=パスワードログインの撤廃 ◦ 単なる「機能追加」ではなく、「運⽤の変更(パスワードレス)」 まで踏み込んで初めてスタートライン
パスワードを廃⽌した後の世界 • 課題:Passkey紛失‧デバイス移⾏時の復旧 ◦ iPhoneからAndroidへの乗り換えなどでPasskeyを失った場合、どう 復旧するか ▪ ex: 数年後にアカウント使いたくなった時...? •
罠:メールリンクによる復旧への依存 ◦ Passkeyでログインを極限まで強固にしても、復旧が「メール1本」 なら破綻する ◦ 攻撃者は最も弱いメール側を狙って乗っ取る • 攻撃者は最も弱い経路を狙う、つまりシステム全体の安全性は最⼩強度 が参照される
復旧の再設計:認証の喪失から「⾝元確認」へ 【NIST SP 800-63】 復旧時も「同等の保証レベル」を維持 • パスキー等を固めても、復旧がメールならそこが最⼩強度の「裏⼝」になる • 認証強度(AAL)に⾒合う厳格な再バインド⼿続きが必須 【現実解の絞り込み】
A. 事前コード(リカバリーキー) ❌ 実効性の課題 すべて失くして困っている⼈間が、英数字 コードを保管しているわけがない B. ⾝元確認の再実施 ⭕ 現実的な解 現実的に成⽴する「唯⼀の選択肢」
復旧の再設計:認証の喪失から「⾝元確認」へ 【従来の⼿法と限界】 【新たな標準と優位性】 従来のeKYC ホ式(⾝分証撮影 + 容貌確認) JPKI(マイナンバーカード × 公的個⼈認証)
ディープフェイク‧偽造の脅威 • 画像加⼯技術の進化により、「⾒た⽬の 確認」は突破されるリスクが激増 ICチップとPKIによる「暗号学的検証」 • 視覚的な偽造が通⽤しない、電⼦証明書 を⽤いた⾼保証な⾝元検証 法改正による「原則廃⽌」への流れ • 犯罪収益移転防⽌法等の⾒直しにより、 画像ベースの確認は縮⼩‧廃⽌の⽅向へ 攻撃難易度を劇的に引き上げる • なりすましのコストを「画像加⼯」から 「物理‧暗号レベル」へ押し上げる
紐付けのパラドックス:⼟壇場で確認しても遅い • では「復旧が必要になった瞬間にマイナンバーカードを出してもらう」で解決するか? ◦ freeeの法⼈ユーザーの住所はマイナンバーの記載のある住所と同⼀? • 安全な復旧を設計しようとすると… ◦ アカウント作成時、Passkey登録時に、どう本⼈確認し、データを紐付けておくか ◦
ライフサイクル全体の設計が必要
⼀つの「点」が、法制度や公的インフラまで繋がる 「Passkeyを安全に導⼊しきる」という1つの⽂脈から連鎖する5つの領域 01 パスワード撤廃の プロセス 02 スマホ紛失時の リカバリー設計 03 復旧時の⾝元確認
04 eKYC アカウント登録時の データ紐付け 公的個⼈認証 バインディング 最初の⼀点の技術が、サービス全体と社会基盤へと波及していく 05 ガイドラインや 法規制への適合 デジタル庁 犯収法など
だから「デジタルアイデンティティ」という⾔葉を使う • 我々が扱っているのは、単なる「認証」や「認可」ではありません ◦ 誰を本⼈と認め(⾝元確認) ◦ どう認証器を紐付け(バインディング) ◦ どう安全にサービスにアクセスさせるか(認証) ◦
失われた時にどう安全に本⼈へ戻し(リカバリー) ◦ その信頼関係をどう維持し続けるか(ライフサイクル) • サービス上に存在する「その⼈」の扱い全体を成⽴させる営み ◦ 「認証‧認可」という⾔葉だけでは溢れ出す ◦ この広⼤な設計領域を表す⾔葉こそが、デジタルアイデンティティです
おわりに:明⽇からの「点」の捉え⽅を変えよう • カンファレンスや勉強会で聞く技術発表は、最初はすべて「点」です • 新しい技術に出会ったら、ぜひ⼀度考えてみてください ◦ 「この技術をサービスに導⼊したら、その前後で何が起きるだろう?」 ◦ その問いを重ねることで、点だった知識が線になり、広がっていきます。 ◦
⾃分にとって、その⾯全体を理解し、サービスの信頼を設計するための⾔葉が デジタルアイデンティティ • Idエンジニアにもなろう!
None