メインコンテンツまでスキップ
画像
紫色の六角形のパターン

OAuthトークンとは?

OAuthトークンは、ユーザーのリソースへのアクセスを承認します。 つまり、ユーザーを認証するのではなく、サービスプロバイダがユーザーに代わって他のリソースへのアクセスを承認するために使用されます。

OAuthトランザクションは、ユーザーがサービスプロバイダのアイデンティティを使用して他のリソースに許可を要求するときに発生します。 リソースはサービスプロバイダに許可を要求し、この許可はリクエストトークンとシークレットの形で提供されます。 次に、リソースはリクエストを認証するために、ユーザーをサービスプロバイダにリダイレクトします。 このとき、リソースはリクエストトークンをアクセストークンおよびシークレットに交換します。 2つのトークンが同じシークレットを共有していれば、OAuthプロセスは完了し、ユーザーはリソースへのアクセス権をサービスプロバイダに正常に委譲できます。

OAuthプロセス

ステップ1

アクセスを要求

アンは、自分のTwitterフィード(サービスプロバイダ)に直接動画を投稿するよう、YouTube(リソース)にリクエストします。 その後、YouTubeはTwitterにアクセス許可を求めます。

デスクに座る女性の画像

ステップ2

リクエストトークンとシークレットの交換

TwitterはYouTubeにリクエストトークンとシークレットを提供します。

鍵とウェブブラウザーの画像

ステップ3

認証

YouTubeはアンをTwitterにリダイレクトしてログインさせます。 アンはTwitterにログイン情報を提供し、YouTubeからのリクエストがユーザーによって開始されたものであることを認証します。

ノートパソコンを使う人物の画僧

ステップ4

アクセストークン交換

リクエストがユーザーによって認証されると、YouTubeはTwitterにリクエストトークンおよびシークレットをアクセストークンと交換するように要求します。 トークンに関連付けられたシークレットが一致した場合、TwitterはYouTubeにアクセストークンを提供し、YouTubeにアクセスを許可します。

鍵とウェブブラウザーの画像

ステップ5

アクセス許可

アンは、安全にYouTubeを利用して、自分のTwitterフィードに直接動画を投稿することができるようになりました。

デスクに座る女性の画像

上記の例は、一般的なOAuthの処理をまとめたものです。 また、OAuthでは、ユーザーが望むときにいつでもトークンを取り消す権利や、リソースごとに異なるレベルのアクセス権をサービスプロバイダに定義するなど、よりきめ細かい制御やパーミッションが可能です。

OAuth 1.0とOAuth 2.0

2012年、OAuth 1.0を大幅に見直したOAuth 2.0が登場しました。このOAuthのバージョンに加えられた変更は、バージョン2.0と1.0に互換性がないほど大きなものでした。OAuth 2.0は、OAuth認証フローにおけるセッションの固定化というセキュリティ上の欠陥に対処するために設計されました。

この問題はOAuth 2.0で解決されましたが、新しいバージョンでは意図的に暗号化、署名、クライアント検証、チャネルバインディングを定義またはサポートしておらず、代わりに実装者がその目的のためにHTTPS/TLSなどの別のセキュリティプロトコルを使用しなければならなくなっています。

OAuth 1.0と2.0の違いをまとめると、次のようになります。

OAuth 1.0とOAuth 2.0の対照表

OAuthと SAML - 何が違うのか?

SAML は、1つのデバイスが1つ以上のデバイスに代わって認証と承認を両方できるようにするフレームワークを記述したXMLバリアント言語です。

JSONのような軽量なデータエンコードの選択肢が登場したことで、OAuthはモバイル端末のユーザーをサポートするために採用されるようになりました。OAuthは、SAMLを置き換える必要性から発展した新しいプロトコルですが、どちらのプロトコルも安全なシングルサインオン(SSO)には欠かせません。

つまり、OAuthはSAMLの代替ではなく、この2つのプロトコルは互いに補完し合うことができます。例えばSSO環境で、SAMLが認証(ユーザーが本物であり、アクセスを許可すべきことを確認する)を担当し、OAuthが認可(特定の保護されたリソースへのアクセスを許可する)を担当する場合があります。