OAuth 1.0 と OAuth 2.0

OAuth の概要

OAuth を車のバレーキーとして考えてみましょう。所有者に無制限のアクセスを許可する通常のキーとは異なり、係員はこの係員付きキーを、グローブ ボックスやトランクにアクセスせずに車を一時的にスピンさせるためにのみ使用します。OAuth を使用すると、Amazon、Facebook、Google、Instagram、LinkedIn、Netflix、Paypal、Microsoft、Twitter などのサードパーティ サービスでエンド ユーザーのアカウント情報を使用できるようになります。これらの企業は多くのサードパーティ アプリケーションと連携しており、ユーザーに次のことを許可することがよくあります。ニュース Web サイト、ブログ プラットフォーム、オンライン ビデオ ゲームなどのアプリ内で認証情報を共有します。

たとえば、Facebook 上の別のアプリにログインするときに、ユーザーは Facebook ログイン ボタンをクリックすることがあります。その後、Facebook がユーザーを自動的に認証し、Web サイトは Facebook からの許可を得てユーザーにアクセスを許可します。OAuth は、Gmail などの電子メール認証にも使用されます。この認証では、Web サービスが別のデバイス内の保護されたリソースにアクセスできるため、ユーザーは 1 回のログインで 2 つの異なるサービスにアクセスできます。

OAuth バージョン:

OAuth 2.0はOAuth 1.0のフレームワークを完全に書き直したもので、1.0バージョンでは用語や用語が異なるプロトコルとして扱われます。機能の主な違いは、両方のバージョンが職務とエンドユーザー エクスペリエンスを分類する方法です。

OAuth 1.0 にはコンシューマー、サービス プロバイダー、およびユーザーがあり、リソース サーバーと認可サーバーの役割を明示的に分離しません。

一方、OAuth 2.0 には、クライアント、認可サーバー、リソース サーバー、およびリソース所有者があります。そのため、これらのバージョンには下位互換性がありません。OAuth 2.0 は、Web アプリケーション、デスクトップ アプリケーション、携帯電話、スマート デバイス、および API ベースのサービスなどの非ブラウザベースのアプリケーションに特定の認証フローを提供します。

OAuth 1.0

⇒ ユーザー A は、アプリ 1 がアプリ 2 のデータにアクセスできるようにしたいと考えています

⇒ アプリ 1 は、ユーザー A によって開始されたアプリ 2 への接続リクエストを送信します

⇒ アプリ2はアプリ1からのリクエストを受け付けます

⇒ アプリ 2 がアプリ 1 に一時トークンを送信します

⇒ アプリ 1 はユーザー A をログインにリダイレクトするか、事前にフォーマットされた URL も使用できます

⇒ ユーザー A がアプリ 1 で認証に成功すると、アプリ 1 はユーザー A にアプリ 2 のリソースへのアクセス許可をアプリ 2 に与える承認を求めます。

⇒ 承認するとアプリ1に通知

⇒ アプリ 1 は一時トークンを使用してアプリ 2 に新しいアクセス トークンを要求します

⇒ アプリ 2 はリクエストを承認し、新しいアクセス トークンを送信します

⇒ アプリ 1 は新しいアクセス トークンを使用してアプリ 2 のデータにアクセスできるようになりました

OAuth 2.0

⇒ ユーザー A は、アプリ 1 がアプリ 2 のデータにアクセスできるようにしたいと考えています

⇒ アプリ1が認可サーバーにアプリ2へのアクセスを要求

⇒ ユーザー A は、上記の手順で受け取ったこの資格情報を使用して認可サーバーに対して認証し、アプリ 2 のデータにアクセスするためにアプリ 1 に認可グラントを返します。

⇒ ここで、アプリ 1 は、上記の手順 3 でユーザー A が付与した認可グラントを使用して、認可サーバーにアクセス トークンを要求します。

⇒ 認可サーバーがリクエストを検証し、アクセス トークンをアプリ 1 に送信します

⇒ アプリ 1 はアクセス トークンを使用してアプリ 1 のデータにアクセスできるようになりました

なぜ OAuth 2.0 なのか?

• ブラウザ以外のアプリケーションのサポートの向上

• 役割の分離

• 有効期間の短いアクセス トークンとリフレッシュ トークン

• リクエストへの署名の複雑さの軽減