OAuth と OpenID Connect の図解ガイド

ノート。 翻訳。: Okta によるこの素晴らしい記事では、OAuth と OIDC (OpenID Connect) がどのように機能するかをシンプルかつ明確な方法で説明しています。 この知識は、開発者、システム管理者、さらには他のサービスと機密データを交換する可能性が高い人気の Web アプリケーションの「通常のユーザー」にも役立ちます。

インターネットの石器時代には、サービス間で情報を共有するのは簡単でした。 あるサービスから別のサービスにログイン名とパスワードを渡すだけで、ユーザーはあなたのアカウントを入力し、必要な情報を受け取ることができます。

「あなたの銀行口座を教えてください。」 「パスワードとお金があればすべてうまくいくことを約束します。 正直です、正直です！」 *ヒッヒッヒ*

ホラー！ ユーザーにユーザー名とパスワードの共有を要求してはなりません。 資格、別のサービスで。 このサービスの背後にある組織がデータを安全に保管し、必要以上の個人情報を収集しないという保証はありません。 クレイジーに聞こえるかもしれませんが、一部のアプリでは今でもこの手法が使用されています。

現在、あるサービスが別のサービスのデータを安全に使用できるようにする単一の標準があります。 残念ながら、このような標準では多くの専門用語や用語が使用されているため、理解が複雑になっています。 この資料の目的は、簡単なイラストを使用してそれらがどのように機能するかを説明することです (私の絵は子供の塗り絵に似ていると思いますか? そうですね!)。

ちなみに、このガイドはビデオ形式でも利用できます。

皆様、ようこそ: OAuth 2.0

OAuth 2.0 は、あるアプリケーションが別のアプリケーションの情報にアクセスする許可を取得できるようにするセキュリティ標準です。 許可証を発行する一連の手順 [許可] （または 同意 [同意]）よく電話する 認可 【認可】 あるいは 委任された承認 [委任された承認]。 この標準を使用すると、アプリケーションにパスワードを与えずに、ユーザーに代わってデータを読み取ったり、別のアプリケーションの機能を使用したりすることができます。 クラス！

例として、「Unlucky Pun of the Day」というサイトを発見したとします。 [今日のひどいダジャレ] そして、毎日のダジャレを電話のテキストメッセージの形で受け取るために、それに登録することにしました。 あなたはこのサイトがとても気に入ったので、それを友達全員と共有することにしました。 結局のところ、誰もが不気味なダジャレが好きですよね？

「今日の残念なダジャレ: 左半身を失った男のことを聞いた? 今では彼は常に正しいです！」 (原文には独自の語呂合わせがあるため、おおよその翻訳です。)

連絡先リストから各人に手紙を書くという選択肢がないことは明らかです。 そして、あなたが少しでも私と同じであれば、不必要な仕事を避けるためにはどんな手段を使ってもするでしょう。 幸いなことに、「Terrible Pun of the Day」だけですべての友達を招待できます。 これを行うには、連絡先の電子メールへのアクセスを開くだけです。サイト自体から連絡先への招待状が送信されます (OAuth ルール)。

「みんなダジャレが大好き！ - ログイン済み？ 「今日のひどいダジャレ Web サイトがあなたの連絡先リストにアクセスすることを許可しますか? - ありがとう！ これからは、時間が終わるまで、あなたの知り合い全員に毎日リマインダーを送信します。 あなたは最高の友達です！」

1. メールサービスを選択してください。
2. 必要に応じて、メール サイトにアクセスし、アカウントにサインインします。
3. Terrible Pun of the Day に連絡先にアクセスする許可を与えます。
4. 「今日のひどいダジャレ」サイトに戻ります。

気が変わった場合に備えて、OAuth を使用するアプリケーションにはアクセスを取り消す方法も用意されています。 Terrible Pun of the Day と連絡先を共有したくないと判断したら、メール サイトにアクセスして、許可されたアプリケーションのリストからそのダジャレ サイトを削除できます。

OAuth フロー

私たちは一般的に呼ばれるものを通過しただけです フロー [フロー] OAuth。 この例では、このフローは目に見えるステップと、2.0 つのサービスが情報の安全な交換について合意するいくつかの目に見えないステップで構成されています。 前の「今日のひどいダジャレ」の例では、「認証コード」フローとして知られる最も一般的な OAuth XNUMX フローを使用しています。 【「認可コード」の流れ】.

OAuth の仕組みの詳細に入る前に、いくつかの用語の意味について説明しましょう。

• リソース所有者:

  
  
  あなただ！ あなたは自分の資格情報とデータを所有し、自分のアカウントで実行される可能性のあるすべてのアクティビティを制御します。

• クライアント:

  
  
  に代わってアクセスまたは特定のアクションを実行したいアプリケーション (たとえば、「今日のひどいダジャレ」サービス) リソース所有者' 。

• 認可サーバー:

  
  
  知っているアプリケーション リソース所有者'a、そしてその中であなたは リソース所有者「すでにアカウントを持っています。

• リソースサーバー:

  
  
  アプリケーション プログラミング インターフェイス (API) またはサービス クライアント 代理で利用したい リソース所有者' 。

• URIをリダイレクトする:

  
  
  そのリンクは、 認可サーバー リダイレクトします リソース所有者'そして許可を与えた後 クライアント'で。 「コールバック URL」と呼ばれることもあります。

• 応答タイプ:

  
  
  受信が期待される情報の種類 クライアント。 最も一般的な 応答タイプ「オームはコードです、つまり クライアント 受け取ることを期待しています 承認コード.

• 対象領域:

  
  
  これは、必要な権限の詳細な説明です。 クライアントデータへのアクセスや特定のアクションの実行など。

• 同意:

  
  
  認可サーバー テイク スコープ要求された クライアントああ、そして尋ねる リソース所有者ああ、彼は提供する準備ができていますか クライアント' 適切な権限を持っています。

• 顧客ID:

  
  
  このIDは識別するために使用されます クライアント'a on 認可サーバー「え。

• クライアントシークレット:

  
  
  これは唯一知られているパスワードです クライアントあなたと 認可サーバー'で。 これにより、情報をプライベートに共有できるようになります。

• 承認コード:

  
  
  有効期間が短い一時コードです。 クライアント 提供しています 認可サーバー代わりに アクセストークン.

• アクセストークン:

  
  
  クライアントが通信に使用するキー リソースサーバーああ。 バッジまたはキーカードのようなもので、 クライアント'データをリクエストするか、アクションを実行する権限を持っています リソースサーバーあなたに代わって。

注意: 認可サーバーとリソースサーバーが同じサーバーである場合があります。 ただし、場合によっては、同じ組織に属していなくても、これらは異なるサーバーである可能性があります。 たとえば、認可サーバーは、リソース サーバーによって信頼されているサードパーティ サービスである場合があります。

OAuth 2.0 の中心的な概念を説明したので、例に戻り、OAuth フローで何が起こるかを詳しく見てみましょう。

1. あなたは リソース所有者、「今日のひどいダジャレ」サービス (クライアントy) 連絡先にアクセスして、すべての友達に招待状を送信できるようにします。
2. クライアント ブラウザをページにリダイレクトします 認可サーバー'a をクエリに含めます 顧客ID, URIをリダイレクトする, 応答タイプ そしてXNUMXつ以上の スコープ （許可）が必要です。
3. 認可サーバー 必要に応じてユーザー名とパスワードを要求し、ユーザーを確認します。
4. 認可サーバー フォームを表示します 同意 (確認) すべてのリスト付き スコープ要求された クライアントああ。 同意するか拒否するかです。
5. 認可サーバー サイトにリダイレクトします クライアント'a、使用して URIをリダイレクトする 一緒に 承認コード (認証コード)。
6. クライアント ～と直接通信する 認可サーバーああ（ブラウザをバイパスする） リソース所有者'a) 安全に送信します 顧客ID, クライアントシークレット и 承認コード.
7. 認可サーバー データをチェックして次のように応答します アクセストークン'om (アクセストークン)。
8. 今 クライアント 使える アクセストークン にリクエストを送信する リソースサーバー 連絡先のリストを取得します。

クライアントIDとシークレット

Terrible Pun of the Day に連絡先へのアクセスを許可するずっと前に、クライアントと認可サーバーは連携関係を確立していました。 認可サーバーはクライアント ID とクライアント シークレット (クライアント シークレットと呼ばれることもあります) を生成しました。 アプリケーションID и アプリシークレット) を作成し、OAuth 内でさらにやり取りするためにクライアントに送信します。

"- こんにちは！ 一緒に働きたいと思っています！ - もちろん、問題ありません! これがあなたのクライアントIDとシークレットです！」

この名前は、クライアント シークレットがクライアントと認可サーバーのみに知られるように秘密にしておく必要があることを示唆しています。 結局のところ、認可サーバーがクライアントの真実性を確認できるのは彼の助けによるものです。

しかし、それだけではありません...OpenID Connect を歓迎してください。

OAuth 2.0 は以下のためにのみ設計されています。 認可 - あるアプリケーションから別のアプリケーションへのデータおよび機能へのアクセスを提供します。 OpenID Connect (OIDC) は、アカウントにログインしているユーザーのログインとプロファイルの詳細を追加する OAuth 2.0 上の薄い層です。 ログイン セッションの構成は、通常、次のように呼ばれます。 認証 【認証】、およびシステムにログインしているユーザーに関する情報 (つまり、 リソース所有者e)、— 個人データ [身元]。 認可サーバーが OIDC をサポートしている場合、それは次のように呼ばれることがあります。 個人データの提供者 [アイデンティティプロバイダー]提供してくれるので クライアント'についての情報があります リソース所有者「え。

OpenID Connect を使用すると、単一のログインを複数のアプリケーションで使用できるシナリオを実装できます。このアプローチは、とも呼ばれます。 single sign-on (SSO)。 たとえば、アプリケーションは Facebook や Twitter などのソーシャル ネットワークとの SSO 統合をサポートし、ユーザーがすでに所有しており、使用したいアカウントを使用できるようにする場合があります。

OpenID Connect のフロー (flow) は OAuth の場合と同じです。 唯一の違いは、プライマリリクエストで使用される特定のスコープが openid、 - A クライアント 最終的には次のようになります アクセストークンと IDトークン.

OAuth フローと同様に、 アクセストークン OpenID Connect では、これは明確ではない値です クライアント'で。 観点から見ると クライアント'а アクセストークン 各リクエストとともに渡される文字列を表します。 リソースサーバー'y、トークンが有効かどうかを決定します。 IDトークン 全く異なるものを表します。

IDトークンはJWTです

IDトークン JSON Web Token または JWT として知られる特別にフォーマットされた文字列です。 (JWT トークンは「ジョッツ」のように発音される場合があります)。 外部の観察者にとって、JWT は理解できない意味不明なものに見えるかもしれませんが、 クライアント ID、ユーザー名、ログイン時刻、有効期限などのさまざまな情報を JWT から抽出できます IDトークン'a、JWT に干渉しようとする試みの存在。 内部のデータ IDトークン' と呼ばれます アプリケーション [請求].

OIDC の場合、次の標準的な方法もあります。 クライアント 個人に関する追加情報を要求する場合があります [身元] から 認可サーバー'a、たとえば、次のような電子メール アドレス アクセストークン.

OAuth と OIDC について詳しく見る

そこで、OAuth と OIDC がどのように機能するかを簡単に確認しました。 さらに深く掘り下げる準備はできていますか? OAuth 2.0 と OpenID Connect について詳しく学ぶのに役立つ追加リソースを次に示します。

• OAuth とは一体何ですか?
• 誰も OAuth や OpenID Connect を気にしません
• PKCE フローを使用した OAuth 2.0 認証コードの実装
• OAuth 2.0 の許可タイプとは何ですか?
• コマンドラインからの OAuth 2.0
• SQL Server を使用して安全な Node.js アプリを構築する

いつものように、お気軽にコメントしてください。 最新ニュースを入手するには、購読してください Twitter и YouTubeでご覧いただけます。 開発者向けの Okta!

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes のセキュリティの ABC: 認証、認可、監査";
• «Kubernetes のユーザーと認可 RBAC";
• «33 以上の Kubernetes セキュリティ ツール";
• «Dockerコンテナのセキュリティ'。

出所： habr.com