OAuth 単語

2件

オーオース

4.3千文字の記事
  • twitter
  • facebook
  • はてな
  • LINE

OAuth(オー・オース)とは、APIの認を委譲するオープンプロトコルである。

概要

OpenIDでは満足できない! はもっと! マッシュアップしたいんだ! は! Oh, ASS!

そんなわけで、外部サイトソフトウェアとのAPI認可する手段として新たに表されたものがこれらしい。

歴史

仕様

一言で言えば、OpenID進化形と考えれば良いのではなかろうか。

OAuthを採用したサイトと、外部サイトソフトウェアとのAPI認可を与えると言う仕組み。
その際には、発行されたトークン暗号化された文字キー)で認を行い、API認可をする。
これにより、外部サイトソフトウェアなどからのログインや、メッセージの表示や送信などの制御ができる。

だが、それを可とするのが長所であり短所でもあったりする。
OAuth認後にユーザーの知らない間になんらかの動作をする危険が危ないことが問題になっている。

というか、OAuthは本来認可のために用いるプロトコルなので、OpenIDとは用途が全く異なる(あちらは認のために用いる)。よく言われるたとえは「OAuthは合OpenIDは身分」というものであり、これを聞けば認にOAuthを使うのがいかにおかしいかがわかるだろう。

だが、それが横行した結果、最終的に出てきたのがOAuth 2.0とOpenID Connectである。手っ取りい話がOpenIDの仕組みをOAuthに取り込んでしまったのだ(要するに身分の発行権限を合に与えたということ)。

というわけで、OAuth 2.0とOpenID Connectを採用している場合は、両者を同時に取り扱って構わない。ただし、それぞれで使うトークンが異なる点には注意。

OAuthの流れ

OAuth 1a(Twitterなどで採用)とOAuth 2.0(Googleなどで採用)では全くフローが異なる。以下、それぞれのフローを順番に見ていくことにする。

OAuth 1aの場合

フローこのリンクexitの通りなのだが、簡単に説明すると、

  1. まずクライアントAPIを利用するサーバログインURLを発行してくれと依頼する
  2. サーバプロバイダ(例えばTwitter)にリクエストに使うための1回限りのトークンを登録する
  3. 登録了後、このURLアクセスせよとサーバクライアント示する(このURLプロバイダ上の認可画面のURL)
  4. クライアントブラウザで3のURLを表示する
  5. プロバイダは「何の権限を要しているか」を表示する。それに対して許可/拒否のチョイスが与えられる。拒否したら認可は失敗する。ここでは許可を選んだとする
  6. コールバックURL(サーバ上にある)へリダイレクトされ、そこにverifier(検証トークン)が渡される。この検証トークンを最初に発行したトークンとともに渡すと、アクセストークンと引き換えができる
  7. 以後、サーバアクセストークンを用いて実際にリソースアクセスを行う

なお、サーバプロバイダとの間のアクセスには、コンシューマキーとコンシューマシークレットというのが必要になる。コンシューマシークレットは絶対に秘密にしておかなければならないものである。

アプリの場合、サーバアプリそのものが担い、コールバックURLアプリ呼び出し用のURLになる。アプリは4でブラウザを起動して許可め、許可を選んだらアプリに戻って残りの処理を行うことになる。

一方、ブラウザの場合、サーバは別に必要であるが、4で表示する際には同じウィンドウで開けばよい。

OAuth 2.0

フローコード・暗黙的・パスワードクライアントの4種類がある。OAuth 2.0はRFC6749にて定められているexit

な使い分けは以下の通り。

クライアントID開して構わない情報である。一方、クライアントシークレット秘密にしておかなければならない情報である。

コードフローの場合

コードフローの場合、認可URLアクセスする際、response_typeにはcode定する(OpenID Connectを行う場合もcodeである。codetoken/id_tokenを一緒に定するとハイブリッドフローになり、暗黙的フローコードフローが混じってしまうため面倒)。そのほかに必要なのはクライアントID認可後のリダイレクトURI・アクセスするリソースの範囲(OpenID Connectの場合ここにopenidが入っている必要がある)・リプレイ攻撃を防ぐためのトークンである。

ここで認可をもらうと、リダイレクトURIにはコードリプレイ攻撃防止用のトークンが渡される。この後、トークンエンドポイントクライアントIDクライアントシークレットリダイレクトURIとともに、grant_typeauthorization_codeを渡す。

これにより、アクセストークンとおよびアクセストークンの有効期限(もしOpenID Connectを要しているならば同時にIDトークンも)、および許可されているならリフレッシュトークンをもらうことができる。IDトークンの説明はこの後、暗黙的フローと一緒に説明する。以後、リソースへのアクセスにはアクセストークンを用いる。

一方、リフレッシュトークンは、アクセストークンの有効期限が切れたとき、アクセストークンと引き換えが可トークンである。

サーバベースの場合は、このフローを用いることになる。

暗黙的フローの場合

暗黙的フローの場合、認可URLアクセスする際、response_typeにはtoken定する(なお、OpenID Connectだけを行う場合はid_token、両方を行う場合はtokenid_tokenの両方を定する)。残りのパラメータはコードフローと同じである。

ここで認可をもらうと、リダイレクトURIにアクセストークンと有効期限と先ほどのリプレイ攻撃防止用のトークンが渡される(OpenID Connectだけの場合はIDトークンのみ、両方を定した場合はアクセストークンIDトークンの両方が渡される)。各トークンの使いコードフローと同様。

ページ完結の場合は、このフローを用いるのがベストである。アプリも、クラックされるリスクを考慮するとこちらを用いるのが通例。

パスワードフローの場合

パスワードフローの場合、トークンエンドポイントクライアントIDクライアントシークレットユーザ名・パスワードスコープを渡すとともに、grant_typepasswordを渡す。これによりアクセストークン(および許可されているならばリフレッシュトークン)をもらうことができる。

ユーザにプラットフォームのユーザ名とパスワードを入してもらうという構造的問題から、一般的なアプリケーションで用いることはなく、一部プラットフォームのBotなどで用いられる程度である。

クライアントフローの場合

クライアントフローの場合、トークンエンドポイントクライアントIDクライアントシークレットを渡すとともに、grant_typeclient_credentialsを渡す。これによりアクセストークンをもらうことができる。

そもそも、ユーザが一切介在しないことからわかる通り、ユーザに関するリソースへのアクセスは一切不可。実際のところ使用例はあまり多くなく、Facebookでのユーザユーザアクセストークンデバッグなどで用いられる程度である(発行されたユーザアクセストークンの管理はクライアント側の責務なので、クライアントフローを用いる)。

IDトークンとは何か

IDトークンとは、認されたユーザが何者であるかなどの情報が入ったトークンである。このIDトークンJSON Web Tokenの形式になっており、ピリオドで区切られた以下の3つの情報から構成される。

署名の仕組みを用いて、署名を行い、それを末尾に追加する。それぞれのコンポーネントはBase64を使って符号化されている。

署名の仕組みと署名に関しては割愛するとして、クレームには何が入っているのか。

まず、どのプロバイダが作ったのかをissで確認する。その後、exp定された有効期限が到来してないかを確認したら、署名の検証を行う。問題がなければ、audで自分宛かどうかを確認し、subユーザの識別子を取得するとともに、その他の情報と合わせてユーザ情報の登録や更新などを行う。

OAuthを採用してるサイト

など。(これ以上追加してもキリがない)

関連項目

関連リンク

この記事を編集する

掲示板

おすすめトレンド

ニコニ広告で宣伝された記事

急上昇ワード改

ほめられた記事

ウォッチリストに追加しました!

すでにウォッチリストに
入っています。

OK

追加に失敗しました。

OK

追加にはログインが必要です。

           

ほめた!

すでにほめています。

すでにほめています。

ほめるを取消しました。

OK

ほめるに失敗しました。

OK

ほめるの取消しに失敗しました。

OK

ほめるにはログインが必要です。

タグ編集にはログインが必要です。

タグ編集には利用規約の同意が必要です。

TOP