「OAuth 2.0」の基本動作を知る：デジタルID最新動向（1）（4/4 ページ）
SNSなど複数のWebサービスが連携して動くサービスが広く使われている。連携に必要不可欠なのが、アクセス権限をセキュアに受け渡すための仕組みだ。本連載ではこのような仕組みのうち、「OAuth 2.0」や「OpenID Connect」「SCIM」の最新動向と技術の内容を紹介する。
ユースケース3：Webアプリケーションを持つサービスがネイティブアプリケーションを提供
ユースケース3では、特定のサービスから離れます。Webアプリケーションを持つサービスがネイティブアプリケーションを提供する際に、どのようにOAuth 2.0を使えばよいのかを紹介します。ここでは前提条件を3つ選びました。
- Webアプリケーションとネイティブアプリケーションの両方を提供するサービスがある
- ネイティブアプリケーションはバックエンドサーバと通信し、Webアプリケーションが持つ機能の一部に特化したサービスを提供する（今後、同様のネイティブアプリケーションを増やす可能性があるなど）
- 登録とログインの処理はWebアプリケーション側で実装済みのものを利用する
単純なWebアプリケーションのネイティブ化ということであれば、全ての機能を実装し直せばよいという対応になるでしょう。ここでは具体的なサービス名を出しませんが、例えばSNSやポータルサイトが個別の機能をネイティブアプリケーションに切り出して、使い勝手を高めるというようなケースに相当します（図10）。
4要素の役割は次のようになります。
| 役割 | 実体 |
|---|---|
| Resource Owner | ユーザー |
| Client | ネイティブアプリケーション |
| Resource Server | 同一サービスのサーバ |
| Authorization Server | 同一サービスのサーバ |
定義1のClient Registrationは、サーバ内の設定を追加するなどで対応できるでしょう。ユーザーがネイティブアプリケーションにログインする際に、外部のWebブラウザを開いてログイン画面（新規登録画面）へと誘導します（図11）。
ユースケース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に関する脆弱性について取り上げ、対策や関連する拡張仕様についても紹介します。
更新履歴
【2017/09/01】過去の連載に向けたリンクを追加しました。
筆者紹介
Ryo Ito（ritou）
http://d.hatena.ne.jp/ritou/
OpenID Foundation Japan Evangelist
OpenID Connectのコントリビュータとして仕様策定に関わっている。
業務ではアイデンティティ技術を用いたSNSサービスの機能強化、新規サービスのプラットフォーム開発に関わり、個人ブログではOpenID／OAuthについて情報発信を行っている。
Copyright © ITmedia, Inc. All Rights Reserved.