ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。});再び、デジタル・アイデンティティの世界へようこそ前回「『OAuth』の基本動作を知る」ではOAuthの仕様がどういうものかについて説明しました。2.0をセキュアに使うために知っておくべきことについて述べていきます。1.0での以下のような反省も踏まえ、「Confidential」と「Public」という2種類のOAuthクライアントタイプを定義しています。Serverでスケールしにくいそれぞれのクライアントタイプは以下のように定義されます。Clientサーバ上で動くWebアプリなどのように、client_secretを秘密にできるクライアント。Clientはクライアント登録時にclient_idとclient_secretという情報を受け取る。ClientJSアプリやスマホ上のネイティブアプリなどのように、client_secretを秘密にできないクライアント。Clientはクライアント登録時にclient_idのみを受け取る。Secret」とも呼ばれる)を受け取っていました。近年、スマホ上のネイティブアプリでOAuthを利用するケースが激増したこともあり、逆コンパイルなどでclient_secretが漏えいする可能性も考慮した結果、このような分類がされています。Token(アクセストークン)の有効期限を変えるといった運用を実現するために、クライアントタイプの情報が利用されています(注1)。Clientの開発者に混乱を生じさせているようです。ServerのAPI戦略なども絡むため、本当の意味で標準化された状況が訪れるまでにはまだ時間がかかるかもしれません。2.0には、アクセス権限付与フロータイプが4種類存在します。OAuth」と呼ばれていたものに該当するタイプです。Clientは基本的にこのフローを利用します。Serverは少ないです。Token」というトークンを発行することができます。Client向けに用意されたフローで、client_secretなしで利用できるように設計されています。Flowに比べると、セキュリティ面は弱くなります。Serverは、クライアント登録時にリダイレクトURLを強制的に登録させたり、同意画面でユーザーに特別に注意を促したりするなど、クライアントのなりすましに対して何らかの対策を行う必要があるでしょう。Serverに渡すフローです。2.0ベースに移行する場合などには使い勝手のいいものです。Client(前述の例の場合はiOSデバイス所有者とiOS自体)の間に強い信頼関係があることを前提にして利用されるケースもあります。Grant(クライアントクレデンシャルグラント)ユーザーの同意を必要としないリソース(アプリの利用状況をはじめとするAnalytics情報など)にアクセスする際に利用されます。Tokenを取得できます。このフローは、ユーザーのリソースにアクセスするために利用されるわけではないのであまり利用機会はないかと思います。Tokenを利用して何ができるのかを知っておくべきでしょう。Grantフローを利用することになるでしょう(注2)。Grantフローを利用させています。詳しくは前章でも紹介した下記の記事をご覧ください。2.0では、クライアントの特性に合わせて複数の権限付与フローを定義しただけでなく、必要とされるセキュリティレベルや既存の認証/認可プロトコルとの相互運用性の確保などを目的として、仕様の多くの部分を拡張可能にしています。2.0への移行を行うための拡張仕様なども策定されています。Token」という署名付きJSONを利用する拡張も存在します。2.0拡張を行っています。2.0の利用方法が述べられています。2.0の実装方法については詳しく述べず、参考になるURLを紹介するにとどめます。2.0に移行する可能性もあります。1.0、2.0ともに仕様の翻訳を行っています。OAuthについてより詳しいことを知りたい方は、以下のURLからそれらの情報にアクセスしていただければ幸いです。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。