APIセキュリティを組織で実現するには~注力する点と設計・実装に入れたい対策~

Postman API Night Tokyo 2026 Summer登壇資料
https://postman.connpass.com/event/401277/

Transcript

1. APIセキュリティを組織で実現するには 注力する点と設計・実装に入れたい対策 織茂駿斗 Copyright © 3-shake, Inc. All Rights Reserved. 1
2. whoami 織茂駿斗 (おりも はやと👼) ID: @riiimparm 株式会社スリーシェイク Sreake事業部 セキュリティ周りの業務支援をしてます 最近はSRE業務にも手を出している AWS, Google Cloud, k8s | Python, Go 個人的によく使うAPI: 自分のドメインに立てているエンドポイント 2
3. 01 書籍の情報 Copyright © 3-shake, Inc. All Rights Reserved. 3
4. 本の紹介 - 概要 翻訳書を執筆させていただきました セキュアAPI 設計・構築・実装を貫く原則 「決して信頼せず、常に検証する。」 AIが書くコードは動く。だが、動くことと安全であることは違う。 著者：José Haro Peralta 訳者：元内 柊也 / 水元 恭平 / 織茂 駿斗 / 小柳 斉 （株式会社スリーシェイク） 出版社：翔泳社 7/15から発売されています 4
5. 本の紹介 - 著者紹介 José Haro Peralta (ホセ ハロ プロータ) セキュリティ専門家 マイクロサービスや API設計、クラウド、インフラ自動化を支援 microapis.io の創設者で、相談業務、トレーニング、ブログ、ツール開発 microapis.ioとは？ マイクロサービス APIの設計・実装・運用を支援するプロジェクト APIのコンサルティングや教育、ワークショップを提供 自動化された APIセキュリティテストツール ”Fencer”開発者 メインフレームワーク : FastAPIやFlask 本書のコード例も Python(FastAPI) 5
6. 本の紹介 - 著者紹介 José Haro Peraltaさん著の書籍 「いかにしてマイクロサービスを構築し APIによってそれらを統合・推進するのか」 著者：José Haro Peralta 訳者：株式会社クイープ 出版社：翔泳社 マイクロサービスAPIの概要 REST APIの設計と構築 GraphQL APIの設計と構築 マイクロサービスAPIのセキュリティ、テスト、デプロイ 6
7. 本の紹介 - 章立て APIセキュリティの考え 方 脆弱性・攻撃の解説 認証認可 高度なAPIセキュリティ 04 認証・認可の脆弱性- 07 APIの認可と認証 09 安全なAPIインフラ- 01 APIセキュリティとは- OWASP Top10 (auth系) セキュア・バイ・デザイン 05 設定と管理の脆弱性- 02 組織とセキュリティの整 合- 06 設計によるセキュリティ L3~L6の対策 - OAuth, OIDC OWASP Top10 (設定・管理) 08 認証と認可の実装 - コード例解説 - 設計上の欠陥 10 金融グレードAPI - FAPI 11 オブザーバビリティ- 脅威モデリング OTel計装 03 セキュリティの原則- 12 セキュリティのテスト シフトレフト / ゼロトラスト - 仕様・Unit Secテスト 7
8. 内容のレベル セキュリティ 入門 初級 中級 上級 入門 初級 中級 上級 API 8
9. 本書の位置づけ この本は「網羅的な入門書」 - 入門書でありながら、扱う範囲は広い セキュリティ観点がいくつかありそれらを通して基礎知識をつける - OWASPベースの整理 & 脆弱なコードそのものを見れる - 認証認可の規格について学べる - ここで紹介されている技術を通じてより詳細に踏み込ん でいくことができる 9
10. 本書の独自のポイント - 脅威モデリングの話から始まる - Pythonベースの脆弱なコード解説 - 金融グレードのセキュリティに言及がある - アプリにとどまらない話(インフラ・オブザーバビリティ) 10
11. どんな方におすすめできるか 「APIからのデータ侵害っ て具体的になにが起きて いる？」 「OAuth, OIDCの仕組 み、いまいちわかってな いです」 脆弱性と攻撃事例を、コードつき で理解したい方 仕組みと、トークン・クレームの 内容まで理解したい方 開発現場でのAPI管理、セキュリ ティ対策への姿勢・取り組み方を 知りたい方（インフラ観点含む） 対応章：Chapter 4, 5 対応章：Chapter 7, 8 対応章：Ch.1, 2, 3 「開発チームでのセキュ リティは？」 11
12. 本書でいうAPIは？ Webのクライアント-サーバーモデルのAPIを前提 主にRESTfulのものを扱う gPRCやGraphQLの話はでてこない ただしセキュリティ原則(1,2,3章) や 認証認可(7,8章) はREST に限らずAPIセキュリティ全般に言える 12
13. 本書で扱わないこと - サプライチェーンセキュリティ対策 - ブラウザ, ローカルアプリのセキュリティ - LLM組み込みのシステムのAPIセキュリティ - 脆弱性管理 - 一般的なサイバーセキュリティ全般 - セキュリティガバナンス 13
14. 02 API開発で最も気にするべき部分 Copyright © 3-shake, Inc. All Rights Reserved. 14
15. 結論 全部。 JWT, OAuth 2.0, OpenID Connect, API Key, Bearer Token, Basic Authentication, Mutual TLS (mTLS), Multi-Factor Authentication (MFA), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), BOLA (Broken Object Level Authorization), BFLA (Broken Function Level Authorization), Broken Authentication, Session Hijacking, Token Expiration, Token Revocation, Refresh Token, Single Sign-On (SSO), Scope, Principle of Least Privilege, Rate Limiting, Throttling, API Gateway, Web Application Firewall (WAF), IP Whitelisting, IP Blacklisting, CORS (Cross-Origin Resource Sharing), DDoS (Distributed Denial of Service), Denial of Service (DoS), Quota Management, Bot Protection, Load Balancer, Circuit Breaker, Unrestricted Resource Consumption, Unrestricted Access to Business Flows, TLS/SSL, HTTPS, Data Encryption at Rest, Data Encryption in Transit, Sensitive Data Exposure, PII (Personally Identifiable Information), Data Masking, Tokenization, Hash (SHA-256), Salt, Key Management System (KMS), Certificate Pinning, Payload Encryption, Excessive Data Exposure, Mass Assignment, SQL Injection, NoSQL Injection, Command Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SSRF (Server-Side Request Forgery), XML External Entity (XXE), OWASP API Security Top 10, Man-in-the-Middle (MitM), Replay Attack, Credential Stuffing, Brute Force Attack, Parameter Tampering, Insecure Deserialization, Unsafe Consumption of APIs, Input Validation, Output Encoding, Schema Validation, JSON Schema, OpenAPI Specification, Content-Type Header, Strict Data Typing, Sanitization, File Upload Security, Payload Size Limit, Audit Logging, Real-time Monitoring, SIEM, Anomaly Detection, Incident Response, Security Logging Failures, Intrusion Detection System (IDS), Intrusion Prevention System (IPS), Zero Trust Network Access (ZTNA), Penetration Testing, Shadow API, Zombie API, Improper Inventory Management, API Versioning, API Deprecation, Security Misconfiguration, Hardcoded Secrets, Environment Variables, Threat Modeling, Secure SDLC, Dependency 15 Scanning, SAST, DAST, DevSecOps, Compliance (GDPR / PCI-DSS)
16. ありがとうございました！ 16
17. 結論 全部。 JWT, OAuth 2.0, OpenID Connect, API Key, Bearer Token, Basic Authentication, Mutual TLS (mTLS), Multi-Factor Authentication (MFA), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), BOLA (Broken Object Level Authorization), BFLA (Broken Function Level Authorization), Broken Authentication, Session Hijacking, Token Expiration, Token Revocation, Refresh Token, Single Sign-On (SSO), Scope, Principle of Least Privilege, Rate Limiting, Throttling, API Gateway, Web Application Firewall (WAF), IP Whitelisting, IP Blacklisting, CORS (Cross-Origin Resource Sharing), DDoS (Distributed Denial of Service), Denial of Service (DoS), Quota Management, Bot Protection, Load Balancer, Circuit Breaker, Unrestricted Resource Consumption, Unrestricted Access to Business Flows, TLS/SSL, HTTPS, Data Encryption at Rest, Data Encryption in Transit, Sensitive Data Exposure, PII (Personally Identifiable Information), Data Masking, Tokenization, Hash (SHA-256), Salt, Key Management System (KMS), Certificate Pinning, Payload Encryption, Excessive Data Exposure, Mass Assignment, SQL Injection, NoSQL Injection, Command Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SSRF (Server-Side Request Forgery), XML External Entity (XXE), OWASP API Security Top 10, Man-in-the-Middle (MitM), Replay Attack, Credential Stuffing, Brute Force Attack, Parameter Tampering, Insecure Deserialization, Unsafe Consumption of APIs, Input Validation, Output Encoding, Schema Validation, JSON Schema, OpenAPI Specification, Content-Type Header, Strict Data Typing, Sanitization, File Upload Security, Payload Size Limit, Audit Logging, Real-time Monitoring, SIEM, Anomaly Detection, Incident Response, Security Logging Failures, Intrusion Detection System (IDS), Intrusion Prevention System (IPS), Zero Trust Network Access (ZTNA), Penetration Testing, Shadow API, Zombie API, Improper Inventory Management, API Versioning, API Deprecation, Security Misconfiguration, Hardcoded Secrets, Environment Variables, Threat Modeling, Secure SDLC, Dependency 17 Scanning, SAST, DAST, DevSecOps, Compliance (GDPR / PCI-DSS) 観点は多いですがAPIの特性に沿って整理すると 守る所はシンプルだったりします
18. 第1章 APIセキュリティとは APIはより重要になる、なり続ける - 公開数の増加 - AIエージェントで開発が進むようになった - 組織の平均保有API数 600ほど (大企業は1万超) - 複雑化 - 連携が増えている(APIの目的) - デバイスの増加 - IoTが進んできた - 生成AIの普及、その基盤 - AIの普及とともにAPI保護の重要性も上がる 18
19. APIセキュリティとは何か APIはそもそもリソースを公開する リソースの裏にはデータがある -> まもりたいのはデータである data external app app Internal app Mid (BFF, APIGW) この対応に不正がないかが一番にま もられる Client app User 不正とは？ -> セキュリティの7要素が観点 19
20. 情報セキュリティ7要素 • • • • • • • 機密性（Confidentiality）: 許可された人のみがアクセス可能（例: パスワード、暗号化） 完全性（Integrity）: 改ざんや破壊がなく正確な状態（例: デジタル署名、バックアップ） 可用性（Availability）: 必要な時にいつでも利用可能（例: 冗長化、DDoS対策） 真正性（Authenticity）: 本人や作成元が自称通りであること（例: 多要素認証） 責任追跡性（Accountability）: 操作者と動作の追跡・証明が可能（例: 監査ログ） 否認防止（Non-repudiation）: 操作の事後否定を不可にする（例: タイムスタンプ） 信頼性（Reliability）: 意図した通りに欠陥なく動作する（例: 品質管理、テスト） data external app app Internal app Mid (BFF, APIGW) Client app APIセキュリティとは 目的: 赤線関係に上の要素を満たす 施策箇所: 各コンポーネント 20 User
21. 分割はセキュリティを増やす HTML ↓ XHR: レンダリング責務の分離 ↓ REST: リソースの分離 ↓ (GraphQL: データ要件の分離) APIの成熟につれ 一枚岩が剥がれ より複雑になっていき 守る点は増えた インテグレーション (=サービス分離は) セキュリティ観点を増やす エージェントがAPI叩くようになりますます リソース分離は加速しそうです 21
22. 観点は多い API Client Mid App POST /xxx URL Param Header Auth Body 22
23. 観点は多い API Client Mid App POST /xxx URL Param Header Auth Body いかなるリクエストコンテキストに対しても コンポーネントは正しく動き、データとユーザーの対応は不正ないか 23
24. 観点は多い - ユーザーはAPIを叩けるか パラメータ・ヘッダに不正はな いか コンポーネント間で検証は適切 か DBデータの正当性 レートリミット範囲内か Mid API ☝ ☝ - Client ☝ POST /xxx URL Param Header Auth Body ☝ ☝ App ☝ ☝ 全体見ていると気にすること多い... 24
25. OWASP API Security Top10整理 脅威 対象レイヤー 問題点 Broken Object Level Authorization オブジェクトアクセス 認可の判断パラメータの想定漏れ Broken Authentication 認証機構 認証機構が突破に脆弱性 Broken Object Property Level Authorization オブジェクトフィールド 可変・可視プロパティが実態とズレている Unrestricted Resource Consumption インフラ, アプリ層 頻度、サイズの制限がない・緩い Broken Function Level Authorization 操作・機能単位 ロール、権限の検証不備 Unrestricted Access to Sensitive Business Flows ビジネスロジック層 振る舞いの制限がない Server Side Request Forgery バックエンド リクエスト送信元の検証不備 Security Misconfiguration インフラ層 実行環境の設定不備 Improper Inventory Management ガバナンス層 API管理漏れ Unsafe Consumption of APIs 外部連携 レスポンス受信時の検証不備 25
26. OWASP API Security Top10整理 脅威 対象レイヤー 問題点 Broken Object Level Authorization オブジェクトアクセス 認可の判断パラメータの想定漏れ Broken Authentication 認証機構 認証機構が突破に脆弱性 Broken Object Property Level Authorization オブジェクトフィールド 可変・可視プロパティが実態とズレている Unrestricted Resource Consumption インフラ, アプリ層 頻度、サイズの制限がない・緩い Broken Function Level Authorization 操作・機能単位 ロール、権限の検証不備 Unrestricted Access to Sensitive Business Flows ビジネスロジック層 振る舞いの制限がない Server Side Request Forgery バックエンド リクエスト送信元の検証不備 Security Misconfiguration インフラ層 実行環境の設定不備 Improper Inventory Management ガバナンス層 API管理漏れ Unsafe Consumption of APIs 外部連携 レスポンス受信時の検証不備 いずれもツールだけではテストしにくいところ 26
27. なにがおきているかBOLA・BOPLAフォーカス POST URL Param Header Auth Role Body Date POST URL Param Header Auth Role Body Date Client API POST URL Param Header Auth Role Body Daty Param Header Body Date Mid App 不正リクエストとは脆弱なコンポーネントから見て正常なコンテキストである 27
28. なにがおきているかBOLA・BOPLAフォーカス POST URL Param Header Auth Role Body Date POST URL Param Header Auth Role Body Date API POST URL Param Header Auth Role Body Daty Param Header Body Date 見る観点 Client 認可制御Mid - 認可を過ぎたあと、見ているコンテキス App トに不備がないか 不正リクエストとは脆弱なコンポーネントから見て正常なコンテキストである 28
29. API Mid URL Param Header Auth Body App いかなるセッション内フローにも ビジネスロジックに不正ないか Client URL Param Header Auth Body - API 誰がフローに関与した？ リクエストの流れは正当か Mid App Client URL Param Header Auth Body API Mid App 29
30. API Mid URL Param Header Auth Body App Client URL Param Header Auth Body 見る観点 - クライアントの一貫性 - フローの一貫性 API Mid App Client URL Param Header Auth Body API Mid App 30
31. APIセキュリティ昨今はどこに注力するべきか エンドポイント単位 - 外部入力バリデーション - 認可制御 - コンポーネントが見えているコンテキストにズレはな いか ワークフロー単位 - 正しくないフローを弾けるか - 一貫性したクライアントと証明できているか 31
32. APIセキュリティ昨今はどこに注力するべきか エンドポイント単位 - 外部入力バリデーション - 認可制御 - コンポーネントが見えているコンテキストにズレはな いか ワークフロー単位 - 正しくないフローを弾けるか - 一貫性したクライアントと証明できているか SDLCでどう防ぐか 32
33. ボルトオン方式の限界 「手戻りシナリオ」 組織はリリース前に脆弱性検査を実施している いつものようにプロダクトの新機能リリース直前に検査を行ったところ クリティカルな脆弱性が多数発見 ↓ 修正対応を開発メンバーに再依頼 ・API定義の変更が必要 ・認可処理の実装見直し ↓ プロジェクト停滞・手戻りコスト大 33
34. シフトレフトとは？ SDLCを左から右に並べたとき、従来リリース直前（右端）に集中してい たセキュリティチェックを、より左側の工程へ前倒しする もともとはテスト工学でのアイデア - より上流で検査できないか? - 検査にパスしないと次に進まないルール 34
35. AIDriven開発に組み込むシフトレフトとは？ Test実行は決定論的ツールで行う 35
36. AIDriven開発に組み込むシフトレフトとは？ AIの推論を活かすべきポイント Test実行は決定論的ツールで行う 36
37. AIDriven開発に組み込むシフトレフトとは？ リスク洗い出し スキーマテスト AIの推論を活かすべきポイント Unit, Integration E2E, 契約テスト テストの拡充 Test実行は決定論的ツールで行う ロジック欠陥の推論(ブラックボックス) ツールスキャン 37
38. 第2章 組織とAPIセキュリティの整合 リスク洗い出し 脅威モデリング 「脅威モデリングはチームスポーツである」 API開発に携わるあらゆるロールを集めて現状を整理 STRIDEモデルの紹介 まずはコンポーネント整理を目的に簡単に手を付けること 38
39. 第2章 +α 脅威モデリングは手法が様々 脅威モデリングのフレームワーク - - - STRIDE - 最もポピュラー - 6種類の観点 - 抜け漏れを防ぐのにいい - まずやるならここから PASTA - 攻撃者視点のリスク志向モデル - ビジネスインパクトの考慮がある - 経営陣含めたリスク対応に向いている DREAD - 脅威へのスコアリング - この中で一番定量的 - CVSSのスコアリングに近い 39
40. 第2章 +α 脅威モデリング - STRIDE STRIDEはあくまで観点 DFD図をベースにすることが多い 40
41. 第2章 +α 脅威モデリング 先の図に対して 6観点×サービスコンポーネント で分析 本書ではステークホルダ、開発 チーム、セキュリティチームを交 えての実践が好ましいとあるが... 41
42. 第2章 +α 脅威モデリング AWS Threat Designer awslabs/threat-designer LLM バックエンド: 利用者が用意した LLM エンドポ イント（例：Amazon Bedrock、自社 LLM ゲート ウェイ） 実行場所: 開発者のローカルマシン、 VPC 内のコンテ ナ/VM 上 AWS Security Agentの脅威モデリング機能をオープ ンソースの実装として示したようなもの ビジネスドメインは対話・コードから抽出 42
43. 第2章 +α 脅威モデリング STRIDE-GPT mrwadams/stride-gpt LLM バックエンド: OpenAI / Anthropic / Google / Mistral / Groq、Ollama・LM Studio によるローカルも可 Streamlit Web UI と CLI、MCP サーバーを提 供。Markdown/JSON/SARIF で出力。 Githubのコードリポジトリを入力としているので IaC含むモノレポでないかぎりインフラ層は弱いか ビジネスドメインはを自分で書く 43
44. 脅威モデリング ・とりあえず取り掛かってみること 脅威モデリングは完璧な1回より、継続的な取り組みを重視 ・脅威モデリングのAIエージェントにビジネスドメインを 渡すこと 44
45. 第2章 +α 脅威モデリングもサイクルである 脅威モデリングの活動 1. 私たちは何に取り組んでいるのか 2. 何が問題になる可能性があるか 3. 私たちはどうするつもりか 4. 私たちは十分に仕事をしただろうか システムの変更のたびにこれを回していく 45
46. 第12章 APIセキュリティのテスト テストを拡充させよう - テストは動作保証 いままでは人力のテスト実装が大変 AIによりテストがより書きやすく スキャンツールのパターンマッチが届かない部分をUnit, Integration, E2Eで補えるようになってきた 46
47. 第12章 APIセキュリティのテスト テストを拡充させよう AI登場でテストは書きやすくなった しかしそのテストは実装の動作保証のためだけになっていないか？ def test_get_own_order_detail(client): r = client.get( "/orders/o_7", headers=auth_headers("user_b"), ) UserBが自分の注文を取れることしか確認して いない 「他テナントのIDを 指定したら何が返るべきかのテスト」が無い assert r.status_code == 200 assert r.json()["id"] == "o_7" 拒否テストを作って堅牢化 47
48. 第12章 APIセキュリティのテスト テストを拡充させよう 拒否テストを作って堅牢化 def test_get_other_user_order_denied(client): r = client.get( "/orders/o_1", headers=auth_headers("user_b") ) assert r.status_code in (403, 404) # BOLA拒否 def test_get_order_does_not_expose_ sensitive_properties(client): r = client.get( "/orders/o_7", headers=auth_headers("user_b") ) assert r.status_code == 200 data = r.json() assert "internal_note" not in data assert "stripe_secret_charge_id" not in data assert "payment_gateway_response" not in data # BOPLA拒否 このパターンを脅威モデリングを下にエージェントに作成 48
49. テストで防ぐ ・Unit, Integration, E2Eテストを拡充させる ・特に拒否テスト ・手動診断で見つかっていた項目をシフトレフト 49
50. まとめ(APIセキュリティ、今何をするべきか) Q: どこに注力するべきか 設計時にできること 実装時にできること ▪ エンドポイント単位 •脅威モデリング •Unit, Integration, E2Eテストを拡 •外部入力バリデーション •とりあえず取り掛かってみること •認可制御 •脅威モデリングは完璧な1回より、 •コンポーネントが見えているコンテ 継続的な取り組みを重視 キストにズレはないか ▪ ワークフロー単位 •脅威モデリングのAIエージェント 充させる •特に拒否テスト •手動診断で見つかっていた項目をシ フトレフト にビジネスドメインを渡すこと •正しくないフローを弾けるか •一貫性したクライアントと証明でき ているか 50
51. 余談(書籍から) ・認証認可のOAuth, OIDCの簡単な整理 51
52. 第7章 APIの認可と認証 Q: APIの認可・認証はどういう形をしているか (What) OAuth (認証コードフロー) OIDC リソースアクセスをクライアントに委任 認証をRPがOPに依存 OP (OpenID Provider) 認証  AS 認証 (認可サーバー)  User 委任 依存  User Client   RS (リソースサーバー)  AS RP    UserInfo 52
53. 第7章 APIの認可と認証 Q: APIの認可・認証はどういう形をしているか (What) OAuth (認証コードフロー) OIDC リソースアクセスをクライアントに委任 認証をRPがOPに依存 OP (OpenID Provider) ログイン  AS ログイン  AS (認可サーバー)  User 委任 Client 🔑アクセストークン 🔑   RS (リソースサーバー)  User 🪪 認証 完了 RP  🔑アクセストークン 🪪IDトークン 🔑   UserInfo 53
54. 第7章 APIの認可と認証 Q: APIの認可・認証はどういう形をしているか (What) OAuth (認証コードフロー) OIDC リソースアクセスをクライアントに委任 認証をRPがOPに依存 まず守るのはここ OP (OpenID Provider) ログイン  AS ログイン  AS (認可サーバー)  User 委任 Client 🔑アクセストークン 🔑   RS (リソースサーバー)  User 🪪 認証 完了 RP  🔑アクセストークン 🪪IDトークン 🔑   UserInfo 54
55. 第7章 APIの認可と認証 OAuth アクセストークンを用いてリソースアクセスを委任 - 認可コード横取り -> PKCE (2.0から必須) - だれがトークンを送ってきているのか -> 送信者制約トークン 送信者制約 レイヤー 検証 メリット / デメリット mTLS L4 アクセストークンにクライアント証明書 L4層で信頼 / クライアント証明書管理 DPoP L7 アクセストークンにクライアント公開鍵 秘密鍵署名のJWTも一緒に インフラ変更不要 / 検証が増える PKCEも送信制約トークンもクライアントの身元確認 55
56. 第7章 APIの認可と認証 OIDC OAuthをベースにユーザー属性情報へアクセス - IDトークンでユーザー認証結果を表現 - 保護対象はIDトークン, その後のUserInfo ID Token (OIDC) Access Token (OAuth) 主目的 認証 認可 検証場所 RP OP 検証タイミング 受信直後 リソースアクセス時 気にするところ 使いまわし・すり替え 正規のRPか 56
57. 第10章 金融グレードAPI OAuthをさらに安全に FAPI(Financial-grade API) - OpenID FoundationのAPIセキュリティ標準 FAPI 1.0: 金融特化 / FAPI 2.0 金融に限らない 攻撃モデルの3目標: - 認可, 認証の安全性(トークン保護) セッション完全性: 改ざん・リプレイ防止 セキュリティプロファイル: - 目的: 認可フロー全体のセキュリティ向上 - JAR: リクエストをJWTで署名・カプセル化 - PAR: リクエストを事前プッシュしURI化 送信者制約 詳しくは書籍で... メッセージ署名プロファイル: - 目的: 否認防止(誰が何をしたか証明) PAR + JARM + イントロスペクション + IDトークン署名 57
58. ありがとうございました！ 58