RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（1/2 ページ）

いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。

[Nov，＠IT]

再び、デジタル・アイデンティティの世界へようこそ

　前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。今回は引き続き、

• OAuth 1.0とOAuth 2.0の違い
• OAuth 2.0をセキュアに使うために知っておくべきこと

について述べていきます。

OAuth 1.0とOAuth 2.0の違い

クライアントタイプの定義

　OAuth 2.0では、OAuth 1.0での以下のような反省も踏まえ、「Confidential」と「Public」という2種類のOAuthクライアントタイプを定義しています。

• リクエスト署名やそれに伴うリクエストパラメータの正規化が複雑である
• サーバ間通信を前提としたプロトコル設計により、JSアプリやスマホアプリでは使いにくい
• 署名検証のために「Access Token」と「Client Credentials」の両方が必要であり、大規模なOAuth Serverでスケールしにくい

　それぞれのクライアントタイプは以下のように定義されます。

・Confidential Client

　サーバ上で動くWebアプリなどのように、client_secretを秘密にできるクライアント。Confidential Clientはクライアント登録時にclient_idとclient_secretという情報を受け取る。

・Public Client

　JSアプリやスマホ上のネイティブアプリなどのように、client_secretを秘密にできないクライアント。Public Clientはクライアント登録時にclient_idのみを受け取る。

　OAuth 1.0ではすべてのクライアントが、秘密鍵の役割を果たす「client_secret」（OAuth 1.0では「OAuth Consumer Secret」とも呼ばれる）を受け取っていました。しかし近年、スマホ上のネイティブアプリでOAuthを利用するケースが激増したこともあり、逆コンパイルなどでclient_secretが漏えいする可能性も考慮した結果、このような分類がされています。

　OAuth 2.0では、OAuth Serverが、クライアントタイプに応じて利用できるAuthorization Requestのパターンを限定したり、Access Token（アクセストークン）の有効期限を変えるといった運用を実現するために、クライアントタイプの情報が利用されています（注1）。

注1：ただし、残念ながら現状では、すべてのOAuth Serverが仕様通りにクライアントタイプの使い分けを行っているわけではなく、OAuth Clientの開発者に混乱を生じさせているようです。この辺りは各OAuth ServerのAPI戦略なども絡むため、本当の意味で標準化された状況が訪れるまでにはまだ時間がかかるかもしれません。

【関連リンク】Re: OAuth 2.0のclient_secretって本当に秘密鍵ですか？

http://oauth.jp/re-oauth-20clientsecret

4つのアクセス権限付与フロータイプ

　OAuth 2.0には、アクセス権限付与フロータイプが4種類存在します。うち3つはクライアントの特性に応じたタイプで、残る1つは、OAuth 1.0で非常に特殊な存在であった「2-legged OAuth」と呼ばれていたものに該当するタイプです。

・Authorization Code Grant（認可コードグラント）

　主にConfidential Client向けに用意されたフローで、Confidential Clientは基本的にこのフローを利用します。仕様では、Public Clientによるこのフローの利用を禁止してはいませんが、現状ではPublic Clientに対してこのフローの利用を許可しているOAuth Serverは少ないです。

図1　Authorization Code Grant（認可コードグラント）のフロー

　Access Tokenが期限切れした場合などには、バックグラウンドで新たなAccess Tokenを取得するために用いられる「Refresh Token」というトークンを発行することができます。

・Implicit Grant（インプリシットグラント）

　Public Client向けに用意されたフローで、client_secretなしで利用できるように設計されています。

図2　Implicit Grant（インプリシットグラント）のフロー

　クライアントの認証を行わないフローなので、Authorization Code Grant Flowに比べると、セキュリティ面は弱くなります。このフローをサポートするOAuth Serverは、クライアント登録時にリダイレクトURLを強制的に登録させたり、同意画面でユーザーに特別に注意を促したりするなど、クライアントのなりすましに対して何らかの対策を行う必要があるでしょう。

・Resource Owner Password Credentials Grant（リソースオーナーパスワードクレデンシャルグラント）

　OAuth Clientが直接ユーザーのIDとパスワードを受け取り、それをOAuth Serverに渡すフローです。

　パスワードをサードパーティに知らせることなくAPI連携を行える、というOAuthの特徴からすると不思議な存在ですが、従来ベーシック認証で行われていたAPI連携をOAuth 2.0ベースに移行する場合などには使い勝手のいいものです。

　また、OAuth ServerとOAuth Clientが同じ事業者によって提供されている場合（例：iOS組み込みのFacebook／Twitterの連携など）に、ユーザーとOAuth Client（前述の例の場合はiOSデバイス所有者とiOS自体）の間に強い信頼関係があることを前提にして利用されるケースもあります。

・Client Credentials Grant（クライアントクレデンシャルグラント）

　ユーザーの同意を必要としないリソース（アプリの利用状況をはじめとするAnalytics情報など）にアクセスする際に利用されます。client_idとclient_secretのみでAccess Tokenを取得できます。

　このフローは、ユーザーのリソースにアクセスするために利用されるわけではないのであまり利用機会はないかと思います。

　しかし、client_secretが漏えいした際には第三者にこのフローを使われてしまうリスクがあるため、OAuth Clientの開発者は、利用しているOAuth Serverがこのフローをサポートしているか否か、サポートしている場合はこのフローで得られたAccess Tokenを利用して何ができるのかを知っておくべきでしょう。

　通常は上記4つのフローのうち、WebアプリであればAuthorization Code Grantフローを、スマホのネイティブアプリやJSアプリであればImplicit Grantフローを利用することになるでしょう（注2）。

注2：Google APIは例外的に、ネイティブアプリに対してもclient_secretを発行し、Authorization Code Grantフローを利用させています。詳しくは前章でも紹介した下記の記事をご覧ください。

【関連リンク】Re: OAuth 2.0のclient_secretって本当に秘密鍵ですか？

http://oauth.jp/re-oauth-20clientsecret

拡張可能性

　OAuth 2.0では、クライアントの特性に合わせて複数の権限付与フローを定義しただけでなく、必要とされるセキュリティレベルや既存の認証／認可プロトコルとの相互運用性の確保などを目的として、仕様の多くの部分を拡張可能にしています。

　例えば、次回以降に紹介する「OpenID Connect」という仕様はOAuth 2.0を拡張して定義されていますし、エンタープライズで広く利用されているSAMLというプロトコルからOAuth 2.0への移行を行うための拡張仕様なども策定されています。またAccess Tokenの表現形式も、現在はほぼすべてのOAuth Serverで「Bearer Token」と呼ばれるものが利用されていますが、「JSON Web Token」という署名付きJSONを利用する拡張も存在します。

　また仕様とは少し離れますが、Facebookは独自にAccess Tokenの有効期限を延ばす方法を定義していたり、独自のOAuth 2.0拡張を行っています。

参考になるドキュメント類

　すでに多くのOAuth Serverが存在し、各社のドキュメントでOAuth 2.0の利用方法が述べられています。そのためここではOAuth 2.0の実装方法については詳しく述べず、参考になるURLを紹介するにとどめます。

【関連リンク】

Facebook APIでのOAuth利用方法 (OAuth 2.0)

https://developers.facebook.com/docs/authentication/

Twitter APIでのOAuth利用方法 (OAuth 1.0)

https://dev.twitter.com/docs/auth/oauth

Google APIでのOAuth利用方法 (OAuth 2.0)

https://developers.google.com/accounts/docs/OAuth2

Github APIでのOAuth利用方法 (OAuth 2.0)

http://developer.github.com/v3/oauth/

LinkedIn APIでのOAuth利用方法 (OAuth 1.0)

https://developer.linkedin.com/documents/authentication

※上記で2012年8月現在まだOAuth 1.0を採用しているTwitterやLinkedInなどは、近い将来OAuth 2.0に移行する可能性もあります。

　また筆者は個人的に、OAuth.jpというサイトを通じて日本のデベロッパー向けに情報発信を行っており、OpenID Foundation JapanでもOAuth 1.0、2.0ともに仕様の翻訳を行っています。OAuthについてより詳しいことを知りたい方は、以下のURLからそれらの情報にアクセスしていただければ幸いです。

【関連リンク】

OAuth.jp

http://oauth.jp/

OpenID Foundation Japan

http://openid-foundation-japan.github.com