User Agent Flow - Implicit Grant - PKCE

フローの名称

OAuth 2.0 ユーザーエージェントフロー (Implicit Grant)

目的

デスクトップやモバイルアプリがブラウザ経由で Salesforce API へのアクセスをユーザーに許可させるため

主なステップ

(1) クライアントアプリがユーザーを認可 URL にリダイレクト (2) ユーザーがログイン＆同意 (3) Salesforce がアクセストークンを URI フラグメントで返す (4) アプリがトークンを取得して API 呼び出し

response_type パラメータ

常に "token" を指定。これによりアクセストークンが直接返される

リダイレクト URI 要件

Salesforce Connected App に登録済みであること。呼び出しと完全一致が必須

アクセストークンの受け渡し方式

リダイレクト URI の URL フラグメント (#access_token=…) を使ってクライアントサイドで取得

セキュリティ上の制限

クライアントシークレット不要だが、アクセストークンはリフレッシュトークンが得られず、露出リスクあり

主な利用シーン

単発の操作／短命セッションのモバイルまたはデスクトップアプリ

アクセストークンの有効期限

通常数分～1時間程度（Salesforce の設定による）

リフレッシュ トークン

implicit flow では発行されず、再認可が必要

エラー処理

認可拒否やリクエスト不備時、redirect URI に error=、error_description= が返る

ブラウザコンテキスト

外部ブラウザまたはアプリ内埋め込みブラウザが必要

Connected App 側で許可すべき設定

OAuth スコープ（例：api, refresh_token は不可）、callback URL、セキュリティポリシーのユーザー許可設定。

同じフローと他の OAuth フローとの違い

Web Server Flow：authorization code ベースでセキュリットキー必須。より安全だがサーバー実装が必要 / JWT Bearer Flow：サーバー間通信向け。ユーザー介在不要 / Client Credentials Flow：サーバ同士。ユーザー認可不要

利点

実装が簡単でクライアントシークレット不要

欠点

トークン漏洩リスクやリフレッシュ不可、短寿命、スコープ制限

推奨場面

モバイル／デスクトップアプリで短時間のアクセス用途

非推奨場面

長期セッションや高セキュリティ環境

Implicit Grantでは

• 認可コードのステップを省略して

• アクセストークンを直接、URL のフラグメント（#access_token=...）として受け取ります

通常の「Authorization Code Grant（認可コードフロー）」では

• 認可コード（短いコード）をまず受け取る

• そのコードを使ってサーバーからアクセストークンを取得する

For increased security, Salesforce recommend using________ instead of the user-agent flow

OAuth 2.0 web server flow with Proof Key for Code Exchange (PKCE)

一言で言うとPKCE は

盗まれた認可コードが悪用されないようにする「証明キー付き認可コードフロー」です

PKCE仕組み（簡略）： ステップ 1：認可リクエスト時

• アプリはランダムな文字列（code_verifier）を生成

• それをハッシュ化（SHA-256）して code_challenge に変換

• code_challenge を URL に含めて Salesforce に送る

PKCE仕組み（簡略）： ステップ 2：トークンリクエスト時

• アプリは最初の code_verifier を送信

• Salesforce は、最初にもらった code_challenge と一致するか確認

• 一致したらアクセストークンを発行