4章 コアアーキテクチャの概念-IDおよびアクセス管理-
概要
IDおよびアクセス管理（IAM）はアーキテクトが対処する必要のある最も困難なトピックの一つである
この章ではIAMの概念やキー認証のフローを理解する
ポイント
IAMに関する一般的な概念
IAM戦略がユーザエクスペリエンス、システム全体のセキュリティとコンプライアンスに大きな影響を与える
ID、認証、承認、IDストアなどの主要なIAM用語への理解を深める
SAML、OAuth 2.0、OpenID Connect、Kerberosなどの最も一般的なIAM標準のいくつかと、それらが生成または使用するさまざまな種類のトークン (アクセストークン、更新トークン、セッショントークン、IDトークンなど) について説明する
SAML IDP開始、SAML SP開始、OAuth Webサーバー、OAuth JWTフローなど、9つの異なるフローの詳細を理解する
詳細
IAMの一般的な概念を理解する
IAM戦略の目的
企業の顧客と従業員のための統一されたデジタルIDと、このIDとそれに関連付けられたアクセス権を管理するため
背景
ランサムウェア、フィッシング、ソーシャルエンジニアリングなどの攻撃が急増していることを考えれば、適切なセキュリティ計画と戦略を立てずにそれを行うことは、大惨事を招くおそれがある
さらに、最近では、特定のトランザクションが複数のシステムにまたがることを期待するのが一般的である
一部のユースケースでは、スケーラブルでセキュアな統合インターフェイスを使用してシステムを接続する必要がある
他の使用例では、特にユーザが他のアプリケーションに再度ログインすることを必要とせずに、最も簡単な方法で、これらの複数のシステム間でユーザの椅子を旋回させるメカニズムを容易にする必要がある
さらに、ソーシャルネットワークは、今日のインターネットユーザーのすべてではないにしても、大半の日常生活の一部である
そのため、それらを統合するメカニズムを持つことは、今日の顧客エクスペリエンス (CX) の世界では標準的な期待である
また、GDPRのように、ユーザーの個人データを保護する責任が企業の責任の一部と見なされる一般的な規制コンプライアンスも存在する
NYDFSなどのその他の規制では、監査ログにログインしているユーザーのアクティビティをキャプチャして監視するための包括的なメカニズムが必要である
堅牢なIAMアーキテクチャは、このような規制に準拠するための重要な要素である
IAMアーキテクチャの概要と構成要素
IAMアーキテクチャは、エンタープライズポリシーや規制コンプライアンスなどの内部および外部の要件に基づいて、ユーザーに適切なレベルのアクセス権限が付与されていることを確認する必要がある
IAMアーキテクチャに含まれるユーザーには、外部ユーザー(この場合、通常、顧客IDおよびアクセス管理 (CIAM) という用語を使用する)と内部ユーザー (ここでは単にIAMという用語を使用する) がある
IAMアーキテクチャは、今日の接続型エンタープライズアプリケーションにおいて重要である
IAMソリューションの4つの主要コンポーネントは次のとおりである
- IDリポジトリ:各ユーザーの個人情報を保持する場所またはシステム
- 管理ツールボックス:前述のデータを管理、編集、追加、削除する
- 監視プラットフォーム:ユーザーのアクティビティを継続的に監視し、安全な監査ログに保存する
- ポリシーエンフォーサー:ユーザーのアクセス権限を制御および適用する
ユーザー資格情報、トークン、デジタル証明書、指紋リーダー、虹彩リーダー、顔認識、スマートカード、ハードウェアトークンなど、現在、ユーザーの認証に使用されているさまざまなツールがある
また、ここ数年は多要素認証の利用が増加している
多要素認証とは、ユーザーが知っている情報 (ユーザーの資格情報など) と、ユーザーが排他的にアクセスする必要がある情報 (電子メールの受信トレイや携帯電話など) の組み合わせに依存するものである
IAMの用語と定義を理解する
ID
これは、特定の個人や物を認識するために使用する
システムでは、通常、一意の英数字識別子を使用して、国民ID、社会保障番号、または従業員IDなどの個人を認識する
その他のシステムでは、電子メールアドレス形式などの特定の形式で一意の識別子を使用する
特定のユーザーのIDが認識されると、すべての操作はそのコンテキストで実行される
特定のIDを認識して使用を開始するには、そのIDを要求するユーザーが本物であることを確認する必要がある
ここで認証が登場する
認証
これは、特定の個人または物を一意に、安全に、確信を持って識別するために使用されるプロセスまたは一連のプロセスに与えられる用語である
このステップは、ユーザーが1つ以上の手法を使用してIDを証明することが期待される今日のアプリケーションでは明らかになってきており、それが完了すると、アプリケーションは認識されたID (ログインユーザーまたは認証ユーザー) に基づいて動作する
通常、認証は、個人/モノから次の1つ以上の入力を要求することによって行われる
その個人のみが知っているもの (パスワードや一意のキーなど);個人が持っているもの(物理IDカード、ドングル、組み込みチップなど);または識別されたオブジェクトの物理構造に関連するもの (指紋または虹彩スキャンなど)
個人/モノが認証されると、現在のシステム内で何を表示できるかを決定する必要がある
ここで、認可が重要になる
認可
このプロセスは、特定のユーザーを認証した後、特定のシステム内で表示、実行、所有するための適切な権限を付与するために行われる
ソフトウェアアプリケーションでは、一般的に、特定のシステム内で許可されるポリシーとアクセス許可を定義するスーパーユーザー (管理者とも呼ばれる) が存在する
管理者は、他のユーザーの定義/作成も担当する可能性がある
企業は、認可戦略を設計する際に、最小特権の原則の適用を目指すべきである
これには、ユーザー、アプリケーション、およびデバイスに、正常に動作し、必要な機能を提供するために必要な最小限の特権を付与する必要がある
全体的なセキュリティアーキテクチャを設計する際にはこの点に留意し、特にサービスユーザー (統合ユーザーとも呼ばれる) に必要以上の特権を付与しないようにしておく
IDストア
特定のシステムが使用しているユーザー(または、一般に、プリンシパルとも呼ばれるID)に関する情報を保持するために使用されるディレクトリ構造を持つデータベースまたはシステムに付けられる共通名である
パスワードは通常、前に説明したように、逆引き/復号化が不可能なハッシュ値として保存される
IDストアには、ユーザーの認証に必要なその他の情報、およびユーザーを一意に説明するその他のデータに加えて、名前、電話番号、電子メール・アドレスなどの個人情報が含まれる場合がある
IDストアには、特定のユーザに付与される権限を定義するユーザのグループメンバーシップを含めることもできる
IDストアは、単純にデータベースにすることも、Microsoft Active Directory (AD) などの高度なものにすることもできる
IDプロバイダー (IDP)
IDP (またはIdP) は、既知のユーザー/プリンシパルのIDを管理する信頼されたシステムである
通常は、さまざまな識別情報の作成、更新、および一般的な保守などの機能が含まれる
さらに、他のアプリケーションで使用できる認証サービスも提供する
IDPとIDストアの主な違いは、前者では、独自の機能を使用するか、接続されたIDストアに依存して、IDメンテナンスおよび認証サービスを提供できることである
つまり、IDPは、認証に使用される値 (パスワードなど) を維持する必要は必ずしもない
IDPの例としては、Ping Identity、Oktaなどのプロバイダーがある
Salesforce自身は限定的なIDP機能を提供している
サービスプロバイダー
内部ユーザーまたは外部ユーザーに特定のサービスを提供するアプリケーションは、通常、サービスプロバイダー (SP) と呼ばれる
ただし、IAMのコンテキストでは、サービスプロバイダーは通常、IAM機能 (ユーザー管理や認証を含む) を提供するために他のIDプロバイダーに依存するアプリケーションを追加できる
通常、サービスプロバイダーには、独自のユーザーリポジトリ (データベースなど) とユーザーアクセス制御管理コンソール (特定のアクセス許可が特定のユーザーに割り当てられている) がある
SPがIDPに依存して認証、ID管理、許可 (一般にシングルサインオン (SSO) と呼ばれる) を処理する場合は、IDPに保持されているID権限を特定のローカルSPユーザー権限に変換する特別なセットアップが必要である
単純なケースでは、この設定は認証と少数のID管理アクティビティに限定される
Salesforce自体はSPと考えることができる
特定のSSOセットアップでの役割に応じて、SalesforceはIDP、SP、またはその両方の役割を果たすことができる
その他のSPの例としては、Workday、SAPなどのアプリケーションがある
シングルサインオン
SSOという用語は、ユーザーが複数のアプリケーションにアクセスするために1回の認証を許可されるプロセスを説明するために使用される
SSOの一般的な形式では、ユーザーは前述の認証メカニズム (資格情報など) のいずれかを使用して1つのアプリケーションに対して認証を行い、同じSSOメカニズムにリンクされている別のアプリケーションに属するリソースにアクセスする
この場合、ユーザーは再度認証する必要はない
これは、ユーザーインターフェイス (UI) レベルまたはビジネスロジックレベル (通常はAPI経由) のいずれかで発生する
SSOを使用すると、面倒なプロセスである再認証が不要になり、ユーザの生産性を向上させる
さらに、ユーザー認証アクティビティを監視する一元的なメカニズムが提供されるため、セキュリティとコンプライアンスが向上する
SSOのセットアップでは、IDPを使用して、一元化されたユーザ認証およびポリシー強制機能を提供する
たとえば、今日では、企業がSSOを実装して、すべてのシステムが同じログインポリシー(パスワードの複雑さの要件、ログイン制限、追加の検証メカニズムなど)に従っていることを確認するのが非常に一般的である
これらのポリシーと規制は、SSOセットアップの中央単位として機能するIDPによって適用される
このIDPを使用するすべてのアプリケーションはSPと見なされる
SSO設定でのグローバルおよびローカルデータストアの例
Multi-Factor Authentication (MFA) (多要素認証)
多要素認証は認証プロセスが成功した場合に、ユーザーが異なる方法を使用して複数のID検証プロセスに合格する必要があるセキュリティ・メカニズムである
たとえば、ユーザーは、自分が知っているもの (パスワードなど) 、所有しているもの (携帯電話で受信したワンタイムトークンなど) 、および物理的に所有しているもの (指紋など) の提供を要求される場合がある
MFAでは、ユーザーは通常、3つ (またはそれ以上) の異なるセキュリティレイヤーを渡すように要求される
より緩やかなセキュリティメカニズムは、通常、2要素認証 (2FA) と呼ばれ、2つのID検証プロセスを渡すだけで済む
一般的な例は、最初のステップとしてユーザーの認証情報を要求することである
検証に成功すると、ユーザーは1つの入力フィールドを持つ別のページにリダイレクトされ、指定されたユーザーの電子メールアドレスにワンタイムトークンが送信される
ユーザーは、そのワンタイムパスワードトークン (OTP) を入力フィールドに入力するように要求される
この場合も、ユーザーが知っていること (パスワード) と所有していること (自分の電子メール受信トレイへのアクセス権) に依存する
MFAと2FAを使用すると、攻撃者はユーザーのパスワードを推測したり盗んだりするだけで目的のリソースにアクセスできなくなる
SSOを設定すると、このプロセスが簡単に合理化できる
2FA/MFAポリシーの定義、ポリシーの実行、およびポリシーの使用に関する包括的なログの提供は、IDPが完全に処理するタスクである
そのすべてをIDPに任せておけば、信頼関係に基づいてIDPチェックに合格したユーザーを認証することができる
ユーザー・プロビジョニングとプロビジョニング解除
プロビジョニングは、IDリポジトリにユーザーを作成するプロセスである
これには、グローバルIDリポジトリとローカルIDリポジトリが含まれる
通常、各リポジトリ内のユーザーには一連のロールも割り当てられる
プロビジョニング解除はまったく逆のプロセスであり、グローバルおよびローカルのIDストアからID (関連付けられているロールを含む) を非アクティブ化または削除する必要がある
企業にとって、プロビジョニングとプロビジョニング解除のプロセスを合理化することは重要である
新しい従業員は毎日参加し、他の従業員は退職する
また、1つの場所からすべての関連システムへのすべてのユーザーアクセスをオフにすることも重要である
これにより、最適化、効率性、セキュリティ、コンプライアンスの面で多くのメリットがもたらされる
ロールベースアクセス (RBA)
ほとんどのエンタープライズサイズのアプリケーションには、特定の機能、データベースオブジェクト、レコード、またはフィールドにアクセスするためのユーザーの権限を管理するツールまたはモジュールが付属している
このツールは、通常、この場合はロールベースアクセスコントロール (RBAC) と呼ばれ、特定のロールをユーザに割り当てるために使用される
これにより、これらのユーザがネットワーク全体で表示および実行できる内容が制御される
認証によってユーザーを識別すると、承認サーバーは、ログインしたユーザーに適用可能な役割を決定する
場合によっては、両方のアクティビティを同じシステムで実行できる
SSOのセットアップでは、これは通常、次の2つの手順で行われる
- 一連のグローバルロールの定義と管理
グローバルロールは、集中型RBACシステムで定義され、適切なユーザーに割り当てられる
これらの役割は、ユーザーの責任、職務の説明、または特定のシステムで実行された機能 (システム管理者 (北米) 、Salesforceシステム管理者 (北米) など) に基づく場合がある - ローカル・アプリケーションの役割の定義と管理
各SPアプリケーションについて、アプリケーション・ユーザーに割り当てることができる役割/プロファイル/権限のセットを定義する必要がある
これらのローカル・ロールは、グローバル・ロールにマップされる
たとえば、Salesforceシステム管理者–北米グローバルロールは、北米インスタンスのSalesforceシステム管理者と呼ばれるSalesforceプロファイルに変換できる
さらに、指定されたユーザーが期待されるすべての機能を実行できるようにするための一連のアクセス許可セット、機能ライセンス、サードパーティライセンスも含まれる
ロール変換プロセスは、複数の実行方法がある
- ユーザープロビジョニングツール
たとえば、Ping Identityなどの一部のIDPは、標準のSalesforce APIまたはSystem for Cross-domain Identity Management (SCIM) 標準を使用して、Salesforceでユーザーのプロビジョニングとプロビジョニング解除を行うことができる - 統合ミドルウェアを使用する
次の図は、SSO設定のグローバルロールと変換されたローカルロールを示す例である
SSO設定でのグローバルロールと変換されたローカルロールの例
生体認証
指紋、網膜スキャン、音声、顔認識などの生体属性を使用して個人を一意に識別するプロセスのことである
多くの企業では、2FAまたはMFAメカニズムとして何らかの生体認証を採用しており、ユーザーは1つの認証メカニズム(パスワードなど)を使用してポータルにログインする
これが完了すると、ユーザーがモバイルで使用するモバイルアプリケーションにプッシュメッセージが送信される
その後、ユーザーはアプリケーションを開き、モバイルデバイスの生体認証機能を利用してユーザーを再度認証する
認証が成功すると、メッセージがサーバに送り返され、認証プロセスで定義された次のステップに進む
次の図は、2要素認証メカニズムとしての生体認証の使用を示している
– 二次認証メカニズムとしての生体認証の使用
-
サービスとしてのID (IDaaS)
これは、SaaS方式でIDサービスを提供するソリューションである
これらのソリューションの中には、ユーザープロビジョニングやプロビジョニング解除など、さまざまなレベルのIAM機能を提供するものもある
一部のプロバイダーは、オンプレミスでホストできる形式でソリューションを提供する
これらのプロバイダーの例としては、Okta、Microsoft Azure ID管理、Ping ID、ある程度はSalesforceなどがある -
リスクベース認証 (RBA)
この手法では、さまざまなツールとアルゴリズムを使用して、セキュリティで保護されたリソースにアクセスしようとしているユーザーまたは認証しようとしているユーザーのリスクスコアを計算する
計算されたリスクスコアに基づいて、ユーザーは2要素以上の認証を提供するように求められる場合がある
特定のユーザーのリスクスコアを計算するアルゴリズムは、IPアドレスの範囲、特定の時刻、ユーザーのブラウザー内の特定のドメインからのcookieの存在、特定のユーザーが最後に正常にログインした時刻、その他の多くの高度なアルゴリズムなど、多くの要因に依存する可能性がある
これ以外にも、複雑なロジックから機械学習、人工知能まで、さまざまなものに依存する可能性がある
RBAは、ユーザーエクスペリエンスを不必要に乱雑にすることなく、高いレベルのセキュリティを確保するための説得力のある方法を提供する -
Lightweight Directory Access Protocol (LDAP)
これは、階層型ディレクトリ構造に格納されたデータと対話するための標準化されたメカニズムを提供するために設計されたプロトコルである
LDAPは、これらの構造から効率的にデータを格納および取得できる
Microsoft Active Directory (AD) は、企業データ(通常、ポリシー、ロールおよび権限)を階層構造で格納するツールの一例である
LDAPは、Microsoft ADなどのディレクトリ・サービス・データベースと効率的に通信および対話できるプロトコルである
レビューボードのシナリオでも、実際にも、LDAPを使用してApache Directory、OpenLDAP、JXplorerなどの他のディレクトリー・サービス・データベースと通信するユースケースがある
具体的には、Microsoft Active Directoryフェデレーションサービス (ADFS) やLDAP全般 (前述のIDaaS製品など) など、ADと連携するように構築されているツールとIDPを理解する必要がある -
サービスユーザーとコンテキストユーザーの認証
一部のユースケース (特にAPIにアクセスする場合) では、通常、認証は2つの方法のいずれかを使用する
単一の統合ユーザーの認証のみが必要な名前付きプリンシパルを使用して認証するか、ユーザーごとのポリシーに従う
最初のケースではターゲットシステムの操作は統合ユーザーのコンテキストで動作する
つまり、接続されている各ユーザーにきめ細かいアクセス権限を提供する機会が少なくなる
これに対して、2番目のケースでは、ターゲットシステムの操作はログインユーザーのコンテキストで動作する
これにより、接続されているユーザーごとに異なるアクセス許可、ロール、およびプロファイルを定義できる
次の図は、2つの異なるアプローチを示している
サービスユーザー認証とコンテキストユーザー認証の違い
一般的なIAM標準の理解
アーキテクトとして、IAM標準に精通し、それらがどのように動作し、互いにどのように異なるかを理解し、それらの使用をいつ提案するかを正確に理解する必要がある
一般的なIAM標準について
-
Security Assertion Markup Language (SAML)
SAML標準は2001年に作成された
SAMLは認証と認可の両方の標準とみなされており、XMLに基づいている
SAMLでは、SPはIDPに対して、SAMLアサーション・リクエストを使用してユーザー/プリンシパルを認証および認可するように要求できる
IDPはSAMLアサーション応答で応答する
他のフローでは、プリンシパルは、さまざまなシステム (SP) へのリンクを含む特定のWebページから開始できる
各リンクには、IDPによって生成されたSAMLアサーションが含まれる
そのリンクをクリックすると、アサーションがターゲットSPに送信され、SPとIDPの間に確立された信頼関係に基づいてSPがSAMLアサーションを検証する
その後、プリンシパルにSPへのアクセス権が付与される
SAMLアサーションは、デジタル署名の拡張形式であるXML署名ラッピングを使用して署名される
デジタル証明書を使用して、IDPとSPの間に信頼が確立される
セットアップフェーズでは、通常、アーキテクト/開発者/コンフィギュレータがIDPによって共有されている証明書をSPにアップロードする
SPはこの証明書を使用して、将来IDPから受信するSAMLアサーションを検証する
SalesforceはSAML V 1.1とV 2.0の両方をサポートしている
SAML IDP開始フローとSAML SP開始フローという2つのSAML関連フローがある
SAMLはSSOに最適であり、携帯電話やJavaScriptにはあまり適しておらず、APIではあまり一般的ではない -
オープン認証 (OAuth)
OAuthは、特定の問題を解決するために作成されたオープン標準であり、通常はアクセス委任またはセキュリティで保護された委任アクセスと呼ばれる
これは、アプリケーション (通常はクライアントと呼ばれる) がユーザーの代わりにリソースにアクセスしたり、サーバー (通常はリソースサーバーと呼ばれる) でアクティビティを実行したりできるようにするだけのものである
標準では、ユーザーがクライアントと資格情報を共有する必要なく、このプロセスが容易になる
これは、IDPによって発行されたトークンを利用して行われる
トークンには、クライアントがリソースサーバーでアクセスして実行することを許可されている内容の説明が含まれている
現在のバージョンは2.0である
OAuthは通常、認証標準と考えられているが、認証プロセスを擬似認証と見なすことができるという前提に基づいて、認証標準と見なすことを巡っていくつかの議論があった
このトピックを理解し、アクセス委任の正確な意味を理解するために、簡単な例を挙げる
あなたは本をレビューするのに良いウェブサイトを見ている
あなたは素敵な本を読み終え、素晴らしいレビューを書いた
レビューを投稿すると、レビューをFacebookに投稿することに興味があるかどうかを尋ねるメッセージが表示された 「Share on Facebook」 (Facebookで共有) ボタンが表示される
あなたはアイデアが気に入ったので、ボタンを押した
これをするのは初めてである
ここのウェブサイトは、あなたの代わりにFacebookに投稿する許可/承認を得ようと試みる
Facebookにリダイレクトされ;まだログインしていない場合は、標準のログインページが表示される
ユーザーが認証されると、Facebookは、そのウェブサイトがユーザーに代わって投稿する許可を求めていることを通知するメッセージを含むページを表示する
ページには、承認ボタンと却下ボタンも含まれる
承認ボタンを押すと、Facebookによってそのウェブサイトにトークンが発行され、ユーザーに代わって投稿するための限定的な権限がそのウェブサイトに付与される
ウェブサイトはこのトークンを使用してFacebookの認証を行い、Facebookのウォールにレビューを投稿する
Facebookの友人にとっては、これはユーザーが直接行ったアクティビティのように見える
資格情報はFacebookでのみ共有したことに注意する
Webサイトやその他のエンティティと共有するわけではない
通常、webサイトに発行される別のトークンを使用すると、この一連のアクティビティ全体を必要とせずに次回新しいトークンを取得できる
次回そのウェブサイトにレビューを投稿して同じボタンを押すと、そのウェブサイトは前のステップで付与されたトークンを使って再びFacebookの認証を受け、ユーザーに代わって投稿する
これらのトークンの設定によっては、これらのトークンを取り消すまで、これが引き続き発生する可能性がある
- OpenID接続
OpenIDはOAuth 2.0に基づいているが、目的が異なる
SAMLに似たフェデレーション認証メカニズムを提供するように設計されている
OAuth 2.0にさまざまな機能が追加されているが、特に注意する必要があるのは、IDトークンと呼ばれる追加のトークンが生成されることである
IDトークンには、IDPによって追加されるカスタム属性に加えて、認証されたユーザーに関する情報 (名、電子メール、フェデレーションID、要求元クライアントなど) が含まれる
このトークンは、このトークンが発行された個人のIDを確認するのに役立つ
IDトークン自体はデジタル署名されているため、簡単に検証し、内容が改ざんされていないかどうかを確認できる
IDPのデジタル署名によってIDトークンが保護され、IDトークンには生成対象のユーザーに関するキー情報 (フェデレーションIDなど) が含まれているため、IDPを信頼する他のシステム (サービスプロバイダー) によるこのユーザーの認証に使用できる (信頼はデジタル証明書を使用して確立される)
OpenID Connectは現在広く使用されており、Facebook、Twitter、Googleなど、ほとんどのソーシャルネットワークがサポートしている
ソーシャルネットワークをIDPとして使用して他のWebサイトにログインすることをソーシャルサインオンと呼ぶ
ほとんどの場合、OpenID Connectを使用する
- Kerberos
この認証プロトコルは、SSO機能を提供するためにネットワーク (ローカル企業ネットワークなど) で使用される
トークンに似た仕組みのチケットを使用する
Kerberosは、Microsoft Windowsを除くほとんどのシステムで使用されている
統合Windows認証 (IWA) は、Kerberosを利用するMicrosoft製品である (NT Lan Manager (NTLM) などの他のプロトコルと連携して、WindowsユーザーがSSOにActiveDirectoryを使用できるようにすることもできる)
このシナリオを想像する
ActiveDirectory(AD)を使用してすべての従業員のIDを管理する企業の従業員であるとする
午前中にオフィスに到着し、Windowsベースのラップトップを開き、AD資格情報(これは、背後でKerberosチケットを作成する)を使用してドメインに参加するための認証を行う
次に、会社のSalesforceインスタンス (固有のMyDomain URLを持つ) にアクセスする
ただし、再度認証を行う必要はない
Kerberos、IWA、およびSalesforce Identity Connect、Microsoft ADFS、Ping Identity (SalesforceとADの間の認証フローを容易にする) などのツールを組み合わせて、この機能を提供する
さまざまな種類のトークンについて
アーキテクトは、Salesforce実装のIAM戦略を設計および実装するアクティビティを主導することが求められる
トークンはIAM標準の必須要素であり、名前以外の情報も必要である
- アクセストークン
これは、OAuth 2.0とOpenID Connectで使用される用語である
アクセストークンは、アプリケーションが求める最終的なトークンである
これは、アプリケーションがリソースサーバーに対して認証を行い、ユーザーの代わりにリソースを要求できるようにするトークンである
アクセストークンは、Webサービスに対する認証にも使用できる
通常は、ヘッダー内のトークン自体をバイパスする
アクセストークンは、発行元のシステムに応じて複数の形式で書式設定できる
たとえば、Salesforceが発行したアクセストークンは、次の例のような通常のセッションIDの形式をとる
00 DR 00000008 oBT!AQwAQCPqzc_HBE 59 c 80 QmEJD 4 rQKRRc 1 GRLvYZEqc 80 QmEJD 4 AQwAQCPqzc 59 c 80 QmEJD 4
このトークンの値はデコードできない
これは一意のハッシュであり、復号化またはデコードされることは想定されていない
通常は、有効期限と共にキーと値のペアのディクショナリにキャッシュされる
アクセストークンの有効期間は比較的短くなっている(30分、60分、120分など)
これは、セッション・タイムアウトの時間を決定するシステム管理者によって決定される
-
更新トークン
これは、OAuth 2.0とOpenID Connectで使用される別の用語である
更新トークンは、特定のユースケースのクライアントに対して発行される (クライアントの種類と使用される認証フローによって異なる
更新トークンは通常、アクセストークンよりも長い有効期間がある
失効しないように設定できる場合もある
更新トークンは、クライアントアプリケーションによってセキュリティで保護された場所に格納し、定期的または必要に応じて新しいアクセストークンを取得するために使用する必要がある -
IDトークン
これは、OpenID Connect専用のトークンである
このトークンが発行されたユーザーのIDをクライアントアプリケーションが検証するためのメカニズムを提供する
IDトークンには、発行時刻や有効期限などの情報が含まれている
IDPの設定に応じて、ユーザーの一意の識別子 (フェデレーション識別子とも呼ばれる) などの認証されたユーザーに関するデータに加えて、フェデレーション識別子は、従業員ID、電子メールアドレス、または別の種類の一意の識別子などの値にすることができる
IDトークンには、トークンが発行されたクライアントアプリケーションに関する情報も含まれている
最も重要なのは、トークンにはIDPのデジタル署名も含まれており、トークンの内容を検証するために使用できる
IDトークンの形式は、JSONに基づくデータ構造であるJWTに基づいている
適切なパラメーターが渡された場合、アプリケーションは同じOAuth 2.0フローを使用してIDトークンを要求する
たとえば、Webサーバーフローでは、渡されたスコープ引数の一部としてopenidスコープが含まれている場合、クライアントアプリケーションはIDトークンを取得できる -
JWTトークン
JWTは、パーティのIDを他のパーティにアサートしたり、トークン自体に含まれる一連の情報 (クレームと呼ばれる) をアサートしたりするために使用できるデータを書式設定するための標準である
IDトークンは、Json Web Token形式を使用するトークンの1つである
JWTトークンは、署名でき、この場合はJWS (JSON Web Signature) トークンまたは暗号化され、この場合はJWE (JSON Web Encryption) トークンと呼ばれる
一般に、JWTトークンが参照される場合、それは署名付きJWT (実質的にはJWS)であると暗黙的に想定される
JWTトークンが署名も暗号化もされていない場合は、保護されていないJWTを呼び出すことによって明示的に明確になる
JWTの本体はエンコードされる
eyJhbGciOiJIUzI 1 NiIsInR 5 cCI 6 IkpXVCJ 9.eyJzdWiiOiIxMjM 0 NTY 3ODkwIiwibmFtZSI 6 IkpvaG 4 gRG 9 lIiwiaWF 0 IjoxNTE 2 MjM 5 MDIyfQ.SflKxwRJSMeKKF 2 QT 4 fwpMeJf 36 PO ...
www.jwt.io,などのツールを使用してJWTトークンをデコードすると、JWTトークンがヘッダー、ペイロード、署名(JWTという用語を単独で使用する場合、通常はこのJWTが実際にはJWSであることを暗黙的に示している
)の3つの主要部分で構成されていることが分かる
ヘッダーセクションとペイロードセクションは、次の例のようになる
{
"alg":"HS 256",
"typ":"JWT",
"kid":"228",、
}{
"iss":"www.packtpub.com",
"sub":"11050225117732",
"email":"testemail@packtpub.com",
"email_verified":true,
"aud":"825249835659",
"iat":1401908271,
"exp":1401912171
}
iss、aud、iat、expなどの属性は、以前に要求として参照したものである
これらは標準的な要求である
これらは標準のJWTトークンの一部である
IDPはカスタムクレームを追加し、追加情報を含めることができる
iss (発行者) :トークンを発行したプリンシパルに関する識別子を保持する
aud (audience) :クライアントアプリケーションなど、トークンが発行される受信者の識別子を保持する
iat (発行日時) :トークンが発行された時刻
exp (有効期限) :トークンが受け入れられなくなるまでの時間
alg (アルゴリズム) :暗号化またはデジタル署名に使用されるアルゴリズム
kid (キーID) :これはオプションのヘッダー要求
これらは、必ずしもすべてのOpenIDプロバイダーに含まれているわけではない
SalesforceがOpenIDプロバイダーとして構成されている場合、そのIDトークンには、このオプションのヘッダー要求が含まれる
この要求には、トークンの署名に使用されたキーの識別子が含まれている
Salesforce (およびその他のOpenIDトークンプロバイダー) は、JWTトークンの署名に複数の秘密キーを使用するため、受信者が署名の検証に使用できる公開キーを識別できるように、キーID (kid) を指定する必要がある
このパブリックURL https://login.salesforce.com/id/keys,を見ると、Salesforceによって複数のキーが一覧表示されている
それぞれは、一意のキーID (kid) を使用して識別される
Salesforceから署名付きJWTを受け取るアプリケーションは、kidヘッダー要求の値を抽出し、それを使用して、Salesforceによって定期的に発行されるリストから正しい公開キーを検索して、トークンの署名を検証する
Salesforceは、他のOpenIDプロバイダーと同様に、トークンの署名に使用されるキーを定期的に変更できることに注意する
クライアントアプリケーションは、kidをハードコーディングするのではなく、前に説明したように、動的に解決する必要がある
- セッショントークン
セッションIDとも呼ばれ、Webアプリケーションで使用される
セッショントークンは、現在ログインしているユーザーの特定のセッションを識別する一意の文字列(通常、ハッシュ値)である
セッションIDはWebサイトで頻繁に使用され、通常はCookieに格納される
セッションIDは通常、アプリケーションサーバーのキー値ディクショナリにマップできる
このディクショナリには、ログインしているユーザーと、そのユーザーが実行を許可されている内容に関する情報が含まれている
攻撃者がセッションID/セッショントークンを取得できた場合、通常はターゲットアプリケーションサーバーで被害者になりすますことができる
このため、セッションを破棄するために、特定のセキュリティで保護されたWebサイトでの作業が終了した後にログアウトすることを推奨する
これは、セッションIDの存続期間が短く構成される理由でもある
特に、金融サービス・アプリケーション (オンライン・バンキングなど) では、アイドル時間が非常に短い (5分など) とセッションが期限切れになる場合がある
トークンの有効期限 (TTL) は、固定にすることも、ユーザーのアクティビティに基づいて拡張することもできる
つまり、トークンは特定のアイドル時間が経過した後にのみ期限切れになる
この場合、通常はスライディングトークンと呼ばれる
- 認証コード
OAuth 2.0/OpenIDフロー (Webサーバーフロー) のいずれかで使用される
TTLは非常に短く、承認サーバーによって作成され、 (ブラウザー経由で) クライアントアプリケーションに返される
クライアントアプリケーションは、アクセストークン(オプションで更新トークン)と交換するために、承認コードを承認サーバーに送り返す
承認コードはブラウザーを介して返されるため、この手順は非常に迅速に実行されるが、承認コードはエンドユーザーに表示され、いくつかのツールを使用して確認できる
これは、攻撃者 (アクセストークンを取得するために使用できる) によって盗まれるリスクを減らすため、TTLが非常に短い理由である
-
SAMLアサーション
JWTトークンと同様に、SAMLアサーションを使用して、特定のリソース・サーバー/サービス・プロバイダに対してユーザーを認証できる
ユーザーID、発行時刻、有効期限などの情報が含まれている
また、XML署名ラッピングなど、複数のメカニズムを使用してセキュリティ保護することもできる
アプリケーションは、APIに対する認証にSAMLアサーションを利用することもできる -
Salesforceセキュリティトークン
Salesforce APIにアクセスし、基本認証メカニズム (ユーザー名/パスワード) を使用して認証しようとすると、指定されたパスワードにセキュリティトークンを追加する必要がある
トークン自体は、大文字と小文字が区別される英数字キーである
キー承認フローを理解する
SAML 2.0フローの理解
SAML 2.0には、IDP開始、SP開始、およびSAMLベアラアサーションフローという3つの主要フローがある
-
SAML IDP開始フロー
次の図は、SAML IDPによって開始されるフローを示している
このフローは通常、従業員が同じエンタープライズIDプロバイダーにリンクされているすべてのアプリケーション (サービスプロバイダー) にアクセスするための中央の場所/ページを提供する企業によって使用される -
SAML IDP開始フローの図
1.ユーザーがIDPログインページまたはIDPホームページにアクセスする
2.ホームページまたはログインページは、有効なセッショントークンを持つIDPドメインのcookieが保存されているかどうかを確認することによって、ユーザーが認証されているかどうかを確認する
これが指定された日のユーザーによる最初のログインであり、有効なセッショントークンが見つからないと仮定する
この段階でログインページが表示される
3.ユーザーは、ユーザー名とパスワードを入力する (または、IDPで定義されている方法で認証する)
IDPが2 FAまたはMFAを使用するように設定されている場合、ユーザーが認証される前に他の要素が要求される
ユーザーが認証されると、IDPのホームページにリダイレクトされる
4.ユーザーはIDPのホームページ/ランディング・ページに移動する
このページには、IDP for SSOを使用している使用可能なすべてのアプリケーション (サービスプロバイダー) のリンクが含まれている
ユーザーはこれらのリンクのいずれかをクリックする
5.IDPは、IDPの秘密鍵/証明書で署名されたSAMLアサーションを生成する
アサーションはブラウザを介してSPに送信される
6.アサーションはSPに送信される
7.SPはアサーションを受信し、IDPの公開鍵/証明書を使用してアサーションを検証する
ユーザーが認証され、特定のSPドメインのセッション・トークンが作成され、ブラウザのCookieに保存される
ユーザーはSPのホームページにリダイレクトされる
ユーザーが次にSPにアクセスしようとすると、SPはセッション・トークンでCookieを検出する
有効な場合、ユーザーは目的のページにアクセスできる
そうしないと、新しい認証フローが最初から開始される
唯一の違いは、この場合はIDPではなくSPから開始される点である
これは、SP開始フローと呼ばれる
-
SAML SP開始フロー
次の図は、SAML SPによって開始されたフローを示している
このフローは、ユーザーが特定のSPのディープ・リンクにアクセスしようとしたときに使用される
ブックマークに保存されているURL、電子メール内のリンク、ブラウザー履歴からのURL、ユーザーが覚えているURL、またはSPのホームページのURLなどである
ここでの考え方は、ユーザーがSPのリソースの1つにアクセスしようとしている点にある
SPは、そのリソースへのアクセスを許可する前にユーザーを認証する必要がある
これは非常に一般的なフローである -
SAML SP開始フローの図
1.ユーザーは、ディープ・リンクを使用して、または単にSPのホーム・ページにアクセスしようとして、SPにアクセスする
2.SPは、SPのドメインに関連づけられたCookieに保存されている既存の有効なセッション・トークンをチェックする
ユーザーがこのアプリケーション/SPに今日初めてアクセスしようとしたため、このトークンが見つからなかったと仮定する
3.ユーザーは、SAMLアサーション要求を使用してブラウザーを介してIDPにリダイレクトされる
ここでの考え方は、IDPがユーザーを認証し、ユーザーがアクセスしようとしていたSPのページ/URLにユーザーを戻すというものである(たとえば、ディープリンク内のURL (http://www.packtpub.com/books/SF_TAHandBook.htmlなど))
ターゲットURLは、RelayStateというパラメーターで渡される
前の例では、このパラメーターの値は/books/SF_TAHandBook.htmlとなる
このパラメータは、最終的にユーザー認証後にSPに戻され、ユーザーを正しいURLにリダイレクトするのに役立つ
4.ユーザーはIDPログインページ (RelayState値) にリダイレクトされる
5.IDPは、IDPのドメインに関連付けられたCookieに格納されている既存の有効なセッショントークンをチェックする
ユーザーが今日初めてIDPにログインしたため、このトークンが見つからなかったとする
6.ユーザがユーザ名とパスワードを入力する (または、IDPで定義された方法で認証する)
IDPが2 FAまたはMFAを使用するように設定されている場合、ユーザーが認証される前に他の要素が要求される
7.ユーザーが認証されると、SAMLアサーションが作成され、IDP秘密鍵/証明書で署名され、RelayState値とともにブラウザを介してSPに返される
8.SAMLアサーションは、RelayState値とともにブラウザを介してSPに送信される
SPはアサーションを受信し、IDPの公開キー/証明書を使用して検証する
ユーザーが認証され、特定のSPドメインのセッション・トークンが作成され、ブラウザのCookieに保存される
ユーザーは、RelayState値で指定されたSPページにリダイレクトされる
ユーザーは、ステップ1でアクセスしようとしていたURLにアクセスする
次に、SPセッションCookieがまだ有効であると仮定して、ユーザーが同じSPから別のページにアクセスしようとした場合を見てみる
- 有効なSPセッションでのユーザー認証後のSAML SP開始フローの継続の図
1.ユーザーは、ディープ・リンクを使用して、または単にSPのホーム・ページにアクセスしようとして、SPにアクセスする
2.SPは、SPのドメインに関連づけられたCookieに保存されている既存の有効なセッション・トークンをチェックする
前の認証のトークンがまだ有効であると仮定する
3.ユーザーには、目的のリソースへのアクセス権が付与される
次に、SPのセッショントークンの有効期限が切れた後、IDPのセッショントークンの有効期限が切れる前に、ユーザーがSPからページにアクセスしようとするシナリオをもう一度見てみる
これは、IDPトークンの有効期限がSPのセッショントークンよりも長い期間に設定されている場合に発生する可能性がある
- 期限切れのSPセッションと有効なIDPセッションを使用したSAML SP開始フローの継続の図
1.ユーザーは、ディープ・リンクを使用して、または単にSPのホーム・ページにアクセスしようとして、SPにアクセスする
2.SPは、SPのドメインに関連づけられたCookieに保存されている既存の有効なセッション・トークンをチェックする
前の認証のトークンの有効期限が切れているとする
3.ユーザーは、SAMLアサーション要求を使用してブラウザーを介してIDPにリダイレクトされる
RelayStateの値も設定され、渡される
4.ユーザーはIDPログインページ (RelayState値) にリダイレクトされる
5.IDPは、IDPのドメインに関連付けられたCookieに格納されている既存の有効なセッショントークンをチェックする
IDPがアクティブ/有効なセッショントークンを検出したと仮定する
6.SAMLアサーションが作成され、IDP秘密鍵/証明書で署名されて、RelayState値とともにブラウザを介してSPに返される
7.SAMLアサーションは、RelayState値とともにブラウザを介してSPに送信される
8.SPはアサーションを受信し、IDPの公開キー/証明書を使用して検証する
ユーザーが認証され、特定のSPドメインのセッション・トークンが作成され、ブラウザのCookieに保存される
ユーザーは、RelayState値で指定されたSPページにリダイレクトされる
OAuth 2.0/OpenID Connectフローの理解
OpenID ConnectはOAuth 2.0に基づいているため、次のフローのほとんどは両方に適用できる
-
クライアントアプリ
ユーザーの代わりにリソースサーバー上のリソースにアクセスしようとするアプリケーション -
承認サーバー
ログインしたユーザーに適切な承認を付与するサーバー -
リソースサーバー
クライアントアプリケーションがユーザーの代わりにアクセスしようとしているリソースを持つサーバー
たとえば、ユーザーが特定のページまたはWebサービスにアクセスしようとしているMySFinstance.my.salesforce.comなどのSalesforceインスタンスがこれに該当する -
クライアントID/コンシューマーID
特定のクライアントアプリの一意の英数字ID
承認サーバーは、アプリを承認サーバーに登録するときに、特定のクライアントアプリに対してこの値を生成する
通常、アプリの登録はセットアッププロセスの一部として行われるが、場合によっては動的に行われることもある -
クライアントシークレット/コンシューマーシークレット
クライアントアプリが信頼された承認サーバー以外のユーザーまたは外部エンティティに公開しない、機密性の高い値を表す一意の英数字の値
クライアントIDと同様に、承認サーバーは、アプリを承認サーバーに登録するときに、特定のクライアントアプリに対してもこの値を生成する
Webサーバフロー
このフローは、認証コードフローまたは認証コードフローとも呼ばれる
このシナリオは、Webサイト/Webアプリケーションがユーザーの代わりにリソースサーバーからリソースにアクセスしようとしている場合に使用される
Webサイト/Webアプリはサーバーでホストされ、このフローを使用するには、Webサイト/Webアプリが機密性の高いクライアントシークレット値を安全に格納できる必要がある
この値は、エンドユーザーに公開されたり、ブラウザーに返されたり、セキュリティで保護されていないチャネルで交換されたり、承認サーバー以外のエンティティに公開されたりしないようにする必要がある
Webサイト/Webアプリ (この場合はクライアントアプリ) がこの要件を満たすことができない場合は、別のフローを検討する必要がある
このフローは、サーバー間の通信を容易にするが、少なくとも最初の認証時にはユーザーの対話が必要である
フローでは、クライアントアプリにアクセストークン、および必要に応じてIDトークン (プロセス中にopenidスコープが指定されている場合) と更新トークン (プロセス中にrefresh_tokenまたはoffline_accessスコープが指定されている場合) を付与できる
更新トークンを使用すると、クライアントアプリは承認サーバーと通信して、現在のアクセストークンの有効期限が切れたときに新しいアクセストークンを要求できる
更新トークンは期限切れにならないように構成できる
つまり、Webサーバーフローを使用して、クライアントアプリとリソースサーバーの間に、失効しない認証済み接続を確立できる
このフローは、ターゲットアプリケーションに対してミドルウェアを認証するためにも使用できる
たとえば、MuleSoftからSalesforceへの認証、またはその逆
- OAuth 2.0/OpenID Connect Webサーバーフローの図
1.ユーザーがクライアントアプリケーション (webサイト/webアプリ) にアクセスする
※webサイト自体が既にユーザーを識別し、ローカルで (独自の認証メカニズムを使用して) 認証していると仮定する
webサイトは、ユーザーの代わりにリソースサーバーに格納されているユーザーのデータの一部にもアクセスを試みる
Webサイトがユーザーの完全なプロファイルを取得しようとしている可能性がある
2.Webサイトは、現在のユーザーとターゲットリソースサーバーの既存の有効なアクセストークンまたは更新トークンを確認する
これらのトークンは、通常、webサイトをホストしているサーバーに格納される
メモリ、データベースなどの永続的なデータストア、またはその両方に格納される
これは、トークンを所有するユーザーと、トークンを使用するターゲットシステムによって識別される
トークンは、攻撃者や他のユーザーがアクセスできないサーバーに安全に保存する必要がある
このシナリオでは、ユーザーがリソースサーバーからデータを取得しようとするのが初めてであるため、アプリケーションが現在のユーザーのトークンを検出しなかったとする
3.クライアントアプリは、承認要求を送信することによって承認プロセスを開始する
クライアントアプリは、ブラウザーを介してhttps://login.salesforce.com/services/oauth2/authorize,などのターゲット承認エンドポイントにHTTPリダイレクトを実行し、一連のパラメーターを渡す
渡されるキーパラメーターは、client_id (クライアントアプリの一意の英数字ID) とredirect_uri (認証の成功後にユーザーがリダイレクトされるURI)
このURIは、承認サーバーにも登録する必要がある (これは、セットアッププロセス中にも行われる）
response_typeは、OAuth 2.0認可タイプを定義する
これは、使用される認証フローのタイプを定義する
Webサーバーフローの場合、このパラメーターの値はcodeである必要がある
フローの動作を設定するために使用できるオプションのパラメータがいくつかある
その中の「スコープ」は特に重要である
このパラメーターには、認証が成功したときにアプリケーションが使用を許可するように要求するアクセス許可の一覧が含まれる
通常、承認サーバーはこのパラメーターの有効な値を定義する
ただし、full (ログインしているユーザーがアクセスできるすべてのデータへのアクセスを許可する) 、openid (ユーザーエージェントフローまたはwebサーバーフローのいずれかを使用してこのスコープを要求すると、アプリが署名付きIDトークンを受信できるようになる) 、refresh_token (特定の条件下でアプリが更新トークンを受信できるようにする) など、いくつかの一般的なスコープがある
たとえば、リダイレクトの完全なURIはhttps://login.salesforce.com/services/oauth2/authorize?client_id=3M20PaInvUgL9bbWFTS&redirect_uri=https://www.packtpub.com/oauth2/callback&response_type=codeのようになる
4.許可要求が許可サーバーに送信される
5.承認サーバーは、サーバーのドメインに関連付けられているcookieに格納されている既存の有効なセッショントークンを確認する
（ユーザーが今日初めて承認サーバーにログインしたため、このトークンが見つからなかったとする）
6.ユーザーには、許可サーバーによって提供されるログイン画面が表示される
ユーザーは、ユーザー名とパスワードを入力する (または、許可サーバーによって定義された方法で認証する)
サーバーが2 FAまたはMFAを使用するように構成されている場合、ユーザーが認証される前に他の要素が要求される
完了すると、クライアントアプリがリソースサーバー上の特定のスコープにアクセスできるようにするための承認を求める画面がユーザーに表示される
OAuth 2.0/OpenID Connect承認承認画面の例
7.ユーザーが認証され、認証コードが生成され、ユーザーブラウザー (リダイレクト) を介してクライアントアプリに返される
認証コードは、指定されたredirect_uriに返される
前の例では、返される認証コードは次のようになる
https://www.packtpub.com/oauth2/callback& code=aPYmiDiLmlLnM 2 NhXEBgX 01 tpd 1 zWeFSjzk 4 CUTZg 0 Hu 3 kC ==.
8.承認コードは、ブラウザーを介してクライアントアプリに送信される
ブラウザー経由のリダイレクトにより、認証コードが攻撃者に公開される可能性があることに注意が必要である
ただし、TTLは非常に短く、クライアントシークレット値 (クライアントアプリのみが知っていることが想定されている) の必要性など、攻撃者が使用することを防ぐ他の保護メカニズムがある
9.クライアントアプリは承認コードを受け取る
これを使用して、承認サーバーからアクセストークンを取得する
これは、認証コードとその他の値を特定のサーバーエンドポイントにポストすることによって実現される
渡されるその他のパラメーターには、grant_type (この値は指定されたフローのauthorization_codeである必要がある) 、redirect_uri (このパラメーターの値はこの段階でのみ検証に使用され、手順3で使用した値と一致する必要がある) 、code (このパラメーターには承認コードの値が含まれる) 、client_id (これは重要なパラメーターであり、クライアントアプリでのみ認識される機密性の高いクライアントシークレット値を含める必要がある)、およびclient_secretが含まれる
攻撃者がクライアントシークレットにアクセスできると仮定した場合、認証コードを使用してアクセストークンを取得できる(通常は他にもいくつかの保護メカニズムが含まれているが、攻撃者はそれらを回避する方が簡単であることがわかる)
このため、クライアントシークレットは、クライアントアプリをホストしているサーバーの安全な場所に格納する必要がある
10.承認サーバーはポスト要求を受信し、アクセストークンを発行する
必要に応じて、scopeパラメーターで渡された値に応じて、サーバーは更新トークンとIDトークン (OpenID Connect) を生成することもできる
これらのトークンは呼び出し元に返される(通常、JSON形式)
11.クライアントアプリはトークンを受け取る
必要に応じて、クライアントアプリがIDトークンを受信した場合、アプリはそのトークンを検証する必要がある (承認サーバーの公開キーを使用して署名を検証することによって)
クライアントアプリは、アクセストークンを使用して、リソースサーバーから目的のリソースを要求する
12.リソースサーバーは、要求されたリソースを送信して応答する
ここで、ユーザーがページを更新した場合、クライアントアプリはリソースサーバーからユーザーのプロファイルの詳細を再度取得しようと試みる
しかし、今回はすでにトークンを持っているためフローは次のようになる
初期承認後のOAuth 2.0/OpenID Connect Webサーバーフロー
前の図では、アクセストークンがまだ有効であることを前提としている
そうでない場合、クライアントアプリは更新トークンを使用して、更新トークンフローと呼ばれるプロセスで新しいトークンを取得する
リフレッシュトークンフロー
この方法は、リフレッシュトークンを使用して新しいアクセストークンを取得するために使用される
- OAuth 2.0/OpenID Connect更新トークンフロー
1.ユーザーがクライアントアプリケーション (webサイト/webアプリ) にアクセスする
Webサイトは、ユーザーの完全なプロファイルなど、ユーザーに代わってリソースサーバーに保存されているユーザーのデータの一部にアクセスする
2.Webサイトは、現在のユーザーとターゲットリソースサーバーの既存の有効なアクセストークンまたは更新トークンを確認する
アプリケーションが両方を検出したとする
ただし、アプリケーションはアクセストークンの有効期限が切れていることを認識しない
アクセストークンには、有効期限を示す情報が含まれているものと、含まれていないものがある
アプリケーションでは、アクセストークンの有効期限が切れていることを検出する方法がないと仮定すると、それを使用して目的のリソースを取得しようと試みる
3.クライアントアプリは、アクセストークンを使用して、リソースサーバーから目的のリソースを要求する
4.リソースサーバーは、トークンの有効期限が切れたことを示す応答を返す
通常、リソースサーバーには、すべてのアクティブなアクセストークンと更新トークンを保持するためのストレージ (メモリ内またはデータベース内) がある
期限切れまたは失効したトークンは、そのストレージからパージされる
この場合、リソースサーバーはストレージ内で期限切れのアクセストークンを探したが、見つからなかった(リソースサーバー自体の設定に応じて、期限切れを示すフラグが付いている)
5.クライアントアプリは、次のパラメーターを承認サーバーエンドポイントにポストすることによって、更新トークンを使用して新しいアクセストークンを取得する
grant_type:このフローの値はrefresh_tokenである必要がある
client_id:クライアントアプリの一意のID;client_secret:クライアントアプリのシークレット値が含まれる
refresh_token:このパラメーターには、更新トークン自体が含まれる
6.承認サーバーは、ポスト要求を受信し、アクセストークンを発行して、クライアントアプリに返す
7.クライアントアプリはアクセストークンを受け取り、それを使用してリソースサーバーから目的のリソースを要求する
8.リソースサーバーは、要求されたリソースを送信して応答する
ユーザエージェントフロー
暗黙的フローとも呼ばれるこのフローは、Webサーバーフローよりも安全性が低いと見なされ、主にクライアントシークレット値の安全なストレージを提供できないクライアントアプリに使用される
JavaScript SPA (単一ページアプリケーション) がその好例である
もう1つはモバイルアプリケーションである
- OAuth 2.0/OpenID Connectユーザーエージェントフロー
1.ユーザーがモバイル・アプリケーションを起動する (またはJavaScriptベースのSPAにアクセスする)
ユーザーがこのアプリケーションを初めて開くと仮定し、モバイルアプリケーションが1つのソース (リソースサーバー) からのデータを処理するように設計されていると仮定する
2.アプリケーションは、有効なアクセストークンまたは更新トークンを確認する
ユーザーがアプリを初めて起動することを考慮すると、トークンは見つからない
モバイルアプリは、OAuth 2.0/OpenID Connectユーザーエージェントフローを開始する
渡されるパラメーターは、webサーバーフローで渡されるパラメーターと非常に似ているが、今回はresponse_typeパラメーターの値がtokenである必要がある
たとえば、リダイレクトの完全なURIはhttps://login.salesforce.com/services/oauth2/authorize?client_id=3M20PaInvUgL9bbWFTS&redirect_uri=myapp://callback& response_type=token&state=mystateのようになる
ここで注目すべきもう1つの点は、response_type値以外に、ネイティブモバイルアプリケーションがmyapp ://などのカスタムプロトコルを登録して使用し、myapp :// callbackなどのコールバックを定義できることである
ユーザーエージェントフローの性質と、webサーバーフローよりもセキュリティが低いという事実により、通常は更新トークンを返さない
例外として、クライアントアプリがredirect_uri値でカスタムプロトコルを使用する場合がある
前の例では、前に説明したように、適切なスコープが使用されていることを前提として、フローはアクセストークン、更新トークン、およびIDトークンを返すことができる
3.許可要求が許可サーバーに送信される
4.承認サーバーは、サーバーのドメインに関連付けられているcookieに格納されている既存の有効なセッショントークンを確認する
ユーザーが今日初めて承認サーバーにログインしたため、このトークンが見つからなかったとする
5.ユーザーには、許可サーバーによって提供されるログイン画面が表示される
ユーザーは、ユーザー名とパスワードを入力する (または、許可サーバーによって定義された方法で認証する)
サーバーが2 FAまたはMFAを使用するように構成されている場合、ユーザーが認証される前に他の要素が要求される
完了すると、クライアントアプリがリソースサーバー上の特定のスコープにアクセスできるようにするための承認を求める画面がユーザーに表示される
6.ユーザーが認証され、アクセストークンが生成される
適切なスコープが使用されている場合(これは、モバイルアプリケーションの場合によくある
これは、通常、アプリケーションが次回開かれたときにユーザーが再度認証を要求しないことによって、より優れたユーザーエクスペリエンスを提供するためである
)、更新トークンとIDトークンも生成される
エンドポイントは応答を解析し、その応答から3つのトークンを抽出する
7.これは、IDトークンを受信する場合の省略可能な (ただし強くお勧めする) 手順である
クライアントアプリは、デジタル署名を検証することによってIDトークンを検証する
8.これはオプションの手順である
クライアントアプリは、IDトークン内の情報を使用して、ログインしているユーザーの完全なプロファイルの詳細を要求できる
9.これは、手順8に関連するオプションの手順である
完全なプロファイルの詳細が返される
10.クライアントアプリは、アクセストークンを使用して、リソースサーバーから目的のリソースを要求する
11.リソースサーバーは、要求されたリソースを送信して応答する
ソリューションで使用する予定のフローを説明し、正当化できる必要がある
Webサーバーフローは、セキュリティ対策が優れているため、ユーザーエージェントよりも優先される
ただし、クライアントアプリがコンシューマーのシークレット値を安全かつ安全に格納できない場合 (モバイルアプリケーションやJavaScriptベースのアプリケーションなど) 、ユーザーエージェントフローは、ほとんどの企業にとって許容できるレベルのセキュリティを提供する
JWTベアラフロー
この章では、以前にJWTトークンに触れ、その構造と、作成者のデジタル署名を含む署名セクションがあるという事実について説明した
署名は、JWTの作成者の公開鍵にアクセスできる任意のエンティティによって検証できる
このフローは通常、ユーザーの操作 (ログイン) なしでリソースサーバー上のデータにアクセスすることをクライアントアプリに許可する場合に使用される
JWT自体のデジタル署名は、クライアントアプリの認証に使用される
このフローで想定されるユーザー操作がないことを考慮すると、クライアントアプリは、以前の段階でユーザーによって承認/承認されるか(Webサーバなどの他のフローを使用している可能性がある
ユーザーは、図4.9のような画面を使用してクライアント・アプリケーションを許可する必要がある
)、管理者によって承認される必要がある (そのセットアップは承認サーバーによって異なる)
たとえば、Salesforceが承認サーバーである場合、接続されたアプリ機能で有効にできる [管理者承認済みユーザーは事前承認済み] という設定がある
このフローのシーケンス図を示す
- JWTベアラフロー
1.クライアントアプリは、有効なアクセストークンを確認する
これは、クライアントアプリがリソースサーバーから定期的に(例えば毎日)データを取得するように構成されており、そのためには有効なアクセストークンが必要であることが原因である可能性がある
何も見つからなかったとする
また、使用可能な更新トークンがないと仮定するのも妥当である
更新トークンが使用可能な場合は、JWTベアラーフローを使用するのではなく、新しいアクセストークン (更新トークンフロー) を取得するために使用することをお勧めする
2.クライアントアプリはJWTを生成し、その秘密キー/証明書を使用して署名する
JWTの生成は比較的簡単で迅速であり、ほとんどすべてのプログラミング言語で使用できる既製のライブラリが多数ある
3.承認サーバーはJWTを受信し、クライアントアプリの公開キー/証明書を使用して署名を検証する
セットアップ段階で、承認サーバーと公開キーを共有する必要がある場合がある
署名が検証されると、許可サーバーはJWTからユーザーIDを抽出できる (これは通常、subという変数に格納される)
認可サーバーは、ユーザーIDを使用して、そのIDストア内のユーザーを検索する
一致が検出され、クライアントアプリが既にスコープに対して承認されている場合、承認サーバーは、指定されたクライアントアプリが識別されたユーザーに代わってリソースサーバーにアクセスするためのアクセストークンを生成する
4.アクセストークンはクライアントアプリに返される
5.クライアントアプリは、アクセストークンを使用して、リソースサーバーから目的のリソースを要求する
6.リソースサーバーは、要求されたリソースを送信して応答する
デバイスフロー
この流れを理解するためには、ここでのデバイスの意味を明確にする必要がある
これは主に、インターネットに接続できるが、入力または表示機能に制限がある電子機器を指す
スマートテレビや家電製品がその好例だ
現在、多くのスマートテレビには、Google Androidなどのオペレーティングシステムが組み込まれており、正常に動作するにはユーザーの認証が必要である
また、特定の操作を実行するために、特定のリソースサーバーへのアクセスを承認する必要もある
たとえば、スマートテレビは、プロファイルのアクセス許可と既知の動作に基づいて推奨される番組を表示するために、Googleプロファイルにアクセスする必要がある場合がある
このフローは、デバイスの制限を考慮して、できるだけ簡単に使用できるように設計する必要がある
シーケンス図を見てみましょう
- OAuth 2.0デバイスフロー
1.ユーザーがデバイスの電源を入れる(たとえば、スマートテレビをオンにする)
2.デバイスは、有効なアクセストークンまたは更新トークンを確認する
ユーザーがこのデバイスを初めて使用するため、両方が使用できないとする
3.デバイスは、承認コード要求を承認サーバーエンドポイントにポストする
4.許可サーバーは要求を検証し、通常は検証URLと装置コードを使用して、人間が読めるユーザー・コード/許可コードを発行する
5.これらの値は通常、デバイスの画面に表示される
通常、スマートテレビ画面には、ユーザーコード、デバイスコード、およびユーザーがデバイスを確認するために使用するURLを含むメッセージが表示される
ユーザーは、別のデバイス (ラップトップや携帯電話など) を使用してURLを開くことが求められる
URLによって、ユーザーはデバイスコードとユーザーコードを入力できるページに移動する
このステップが完了すると、デバイスはAuthorization serverによって認識される
場合によっては、ユーザーがいずれかのソーシャルネットワークプロバイダー (Googleなど) を使用してログインし、アプリケーションを承認するように求められることもある
これはWebサーバーのフローによく似ている
ユーザーは、リソースサーバー上の特定のスコープにアクセスするためにデバイスを承認する必要がある
6.収集されたデータは、デバイスの認証と承認に使用される
ブラウザーは、この情報をAuthorization serverにポストする
7.アクセストークンと、必要に応じて更新トークンが生成される
8.この期間中、デバイスは定期的にトークンの承認サーバーをプルする
使用可能になると、デバイスに送信される
9.アクセストークンと更新トークンはデバイスに送信され、安全に格納される
10.デバイスは、アクセストークンを使用して、リソースサーバーから目的のリソースを要求する
11.リソースサーバーは、要求されたリソースを送信して応答する
アセットトークンフロー
このフローは、主にIoTデバイス用に作成される
これは、接続されたデバイスとの通信を検証し、セキュリティで保護することを目的としたオープン規格である
特に、使用する画面がまったくない場合に有効である
IoT管理プラットフォームに登録されたデバイスは、リモートで管理および制御できる
さらに、そのデータがIoTアグリゲーションプラットフォームに安全に流れる
(JWTに基づく) アセットトークンは、特定のデバイス (IoT資産とも呼ばれる) を一意に識別し、認証するために使用される
– OAuth 2.0アセットトークンフロー
1.ログインしているユーザが、新規に機器を登録しようとしている
特定のポータル (ここではクライアントアプリと呼ぶ) を使用して、ユーザーはデバイスIDを入力し、リンクをクリックして認証と登録のプロセスを開始する
2.クライアントアプリはJWTを生成し、その秘密キー/証明書を使用して署名し、それを使用して承認サーバーからアクセストークンを要求する
3.承認サーバーはトークンを受信し、検証して、アクセストークンを発行する (手順2と3は承認サーバーからアクセストークンを要求するためのもので、JWTまたはWebサーバーフローを使用して実行できる)
4.アクセストークンはクライアントアプリに返される
5.クライアントアプリは、デバイスから特定のAPIを呼び出して、デバイス情報を要求する
デバイスはオンラインで、インターネットに接続されていると見なされる
6.デバイスは、デバイスID、シリアル番号などのデバイス情報を送信して応答する
7.クライアントアプリは、完全なデバイス情報を受け取る
これで、アクセストークンと、必要に応じてアクタートークンを使用して、アセットトークンを要求できるようになる
アクタートークンを使用して、資産/デバイス自体に関する情報 (メタデータ) を承認サーバーに渡すことができる
これには、クライアントアプリ(たとえば、この特定の資産をリンクする必要がある取引先ID)によって認識されるカスタム属性を含めることができる
アクタートークン自体はJWT形式であり、承認サーバーが受信時に検証できるように署名できる
アクセストークンとアクタートークンの両方が承認サーバーにポストされ、アセットトークンと交換される
8.承認サーバーは、トークンを受信して検証し、その秘密キー/証明書を使用して署名されたアセットトークン (JWT形式) を発行する
アセットトークンには、最初にアクタートークンに渡された資産自体を記述する標準属性とカスタム属性を含めることができる
9.アセットトークンがデバイスに返される
デバイスはそれ以降、リソースサーバー (IoT集約プラットフォーム) に対して認証を行い、そのデータを送信するために使用できる
ユーザ名とパスワードのフロー
このフローでは、ユーザー資格情報 (ユーザー名/パスワード) を使用してアクセストークンを取得する
このフローは更新トークンを返さず、主にクライアントアプリが承認サーバーと同じ機関によって開発されている場合に、特定のユースケースで使用することを目的としている
- ユーザー名とパスワードのフロー
1.ユーザーは、資格情報を使用してクライアントアプリに対して認証を行う
これは、ユーザーが今日初めてクライアントアプリにアクセスしようとしたときに、使用できるセッショントークンがないことを前提としている
2.クライアントアプリは、受信した資格情報を使用して、承認サーバーからアクセストークンを要求する
アプリは次のパラメーターを渡す
grant_type (このフローの値はpasswordである必要がある);client_id (クライアントアプリの一意のID);client_secret (アプリのクライアントシークレット) 、username (ユーザーからキャプチャされたユーザー名);とpassword (ユーザーからキャプチャされたパスワード)
このフローを使用してSalesforce APIに対する認証を行う場合は、Salesforceセキュリティトークンをパスワードに連結する必要があることに注意が必要である
3.承認サーバーは資格情報を検証し、アクセストークンを発行する
4.アクセストークンはクライアントアプリに返される
5.クライアントアプリは、アクセストークンを使用して、リソースサーバーから目的のリソースを要求する
6.リソースサーバーは、要求されたリソースを送信して応答する