「OAuth 2.0」の基本動作を知る：デジタルID最新動向（1）（4/4 ページ）

ユースケース3：Webアプリケーションを持つサービスがネイティブアプリケーションを提供

　ユースケース3では、特定のサービスから離れます。Webアプリケーションを持つサービスがネイティブアプリケーションを提供する際に、どのようにOAuth 2.0を使えばよいのかを紹介します。ここでは前提条件を3つ選びました。

• Webアプリケーションとネイティブアプリケーションの両方を提供するサービスがある
• ネイティブアプリケーションはバックエンドサーバと通信し、Webアプリケーションが持つ機能の一部に特化したサービスを提供する（今後、同様のネイティブアプリケーションを増やす可能性があるなど）
• 登録とログインの処理はWebアプリケーション側で実装済みのものを利用する

　単純なWebアプリケーションのネイティブ化ということであれば、全ての機能を実装し直せばよいという対応になるでしょう。ここでは具体的なサービス名を出しませんが、例えばSNSやポータルサイトが個別の機能をネイティブアプリケーションに切り出して、使い勝手を高めるというようなケースに相当します（図10）。

図10　既存のWebアプリケーションの機能の一部をネイティブアプリケーション化する

　4要素の役割は次のようになります。

　定義1のClient Registrationは、サーバ内の設定を追加するなどで対応できるでしょう。ユーザーがネイティブアプリケーションにログインする際に、外部のWebブラウザを開いてログイン画面（新規登録画面）へと誘導します（図11）。

図11　ネイティブアプリケーションとWebアプリケーションが連携する場合のOAuth 2.0の動作（全体像）

　ユースケース3では、ClientとAuthorization Server、Resource Serverの3要素が同一サービスに含まれています。場合によっては、アクセス許可への同意をユーザーにも求める画面などを出さずにネイティブアプリケーションに戻る実装となるかもしれません。ここまでの処理が、定義2のObtaining Authorizationに当たります。

　ログイン状態となった後にバックエンドサーバからネイティブアプリケーションで扱うデータを取得する処理が、定義3のAccessing Protected Resourcesの範囲です。

　これらの処理をSDKで実装しておくとよいことがあります。同一サービス内の他の機能をネイティブアプリケーションとして切り出す際にも、サービス内部で定義1のClient Registrationを行うだけで、比較的容易に登録とログインの機能を実装できるでしょう。

ネイティブアプリケーションを使う際の技術課題とは

　ユースケース3はネイティブアプリケーションを使いますから、他のユースケースには存在しない点に気を付けなければなりません。

• ネイティブアプリケーションにアクセスを許可する範囲を適切に設定する
• 新規登録とログイン処理を終えてネイティブアプリケーションに戻る部分を、特に安全に実装する
• Webアプリケーションでパスワードの再確認を必要とするような処理を行うときは、OAuth 2.0以外の仕様を利用する必要がある

　Webアプリケーションと比べて、ネイティブアプリケーションはモバイル端末上で動作する仕組み上、安全な実装をすることが比較的困難です。アクセスを許可する範囲について、ネイティブアプリケーションが必要とする最小限の内容に抑えることで、第三者にアクセス権限を奪われた際のリスクを低くすることができます。

　ネイティブアプリケーションとWebブラウザとのやりとりが安全になるよう実装できていないと、第三者によるセッションハイジャックなどのリスクが発生します。

　Webアプリケーションでパスワードの再確認を必要とする処理をネイティブアプリケーションで実装しようとすると、「いつ、誰がパスワードを再確認したか」といった情報を扱う必要が出てきます。これはOAuth 2.0の仕様でサポートされている範囲を超えており、別の仕様を参照しながら実装していく必要があります（冒頭の囲み記事参照）。

脆弱性対策はどうなっているのか

　今回は、OAuth 2.0の仕様を振り返り、3つのユースケースを紹介しました。ユースケース2と1で取り上げたFacebookへのRead（プロフィール情報を参照してソーシャルログイン）、Write（記事投稿）については、5年前と変わらず広く使われ続けており、より安全な実装のためのノウハウも比較的整っているといえます。

　最後に紹介したユースケース3については、この5年の間で仕様自体が進化しています。

　ネイティブアプリケーションのOAuth 2.0実装については、既存のRFC 6749だけでは対応できない脆弱（ぜいじゃく）性が見つかり、対応するための拡張仕様がRFC化されています。

　次回は、この5年間で見つかったOAuth 2.0に関する脆弱性について取り上げ、対策や関連する拡張仕様についても紹介します。