質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.48%

  • Android

    6628questions

    Androidは、Google社が開発したスマートフォンやタブレットなど携帯端末向けのプラットフォームです。 カーネル・ミドルウェア・ユーザーインターフェイス・ウェブブラウザ・電話帳などのアプリケーションやソフトウェアをひとつにまとめて構成。 カーネル・ライブラリ・ランタイムはほとんどがC言語/C++、アプリケーションなどはJavaSEのサブセットとAndroid環境で書かれています。

  • Google

    633questions

    Googleは、アメリカ合衆国に位置する、インターネット関連のサービスや製品を提供している企業です。検索エンジンからアプリケーションの提供まで、多岐にわたるサービスを提供しています。

  • App Store

    154questions

    App Storeは、Apple社が運営する、iPhone、iPod touch、iPad向けアプリケーションソフトのダウンロードサービスです。携帯電話、Wi-Fiによる無線通信に対応しており、多くのアプリケーションをダウンロード、インストールすることができます。世界中の開発者によってアプリケーションが登録されており、有償のソフトもあればフリーソフトも多く登録されています。

  • OAuth

    105questions

    OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuthの作法、マナー、「アクセストークン」の扱いについて

解決済

回答 2

投稿

  • 評価
  • クリップ 1
  • VIEW 540

CUTBOSS

score 1

OAuthについて、こちらの記事「一番分かりやすい OAuth の説明」が大変に分かりやすかったのですが、「アクセストークン」は、「クライアントアプリケーション」に渡されていました。

これは当然のことだと思いますが、その後、「クライアントアプリケーション」から「全く関係のない別のアプリ」「全く関係のない別のサーバー」へ「アクセストークン」を渡すことが可能で、そこに物理的な制限はないと思いました。

OAuthの思想からすると、これはやるべきではない、やってはいけない、ことのように感じたのですが、実態はどうなのでしょうか?

これは取り締まれるのでしょうか、マナーの問題なのでしょうか?

例えば、Androidアプリ上でアカウント認証して、「アクセストークン」をAndroidアプリは得たとします。

この「アクセストークン」を外部サーバへネットワーク経由で渡してしまえば、そのサーバ上でさも認証したかのように、「Google Drive」から自由に情報を取得することが可能だと思います。

同様に、Androidアプリから、別のAndroidアプリへ共有データとして「アクセストークン」を渡してしまうことも可能で、別のAndroidアプリが「Google Drive」から自由に情報を取得することも可能だと思います。

しかも、そうしていることが、ユーザには分からないようにできるのではないでしょうか。

素朴に、これは「スパイウェア」もどきに感じてしまったのですが、「悪いことしないから」という前提でこういうことやっているサービス、予想ですが、結構、存在しないでしょうか?

例えばこんなアプリをGoogleやAppleにリリースしたら、許されるのでしょうか?

今回、「REST API」を改めて考えてみて、素朴に、疑問に思いました。「アクセストークン」が漏れたら何でもできてしまう。「Google Drive」にアクセスする巷のアプリを何も考えずに使っていますが、実は凄く怖いことなんじゃないかって。Googleはちゃんとそういったことを審査できているのかって。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 2

checkベストアンサー

+3

「一番分かりやすい OAuth の説明」を書いた本人です。

ご懸念の通り、アクセストークンを他のところに持っていけば、使えてしまいます。これは電車の切符に似ていて、自分が買った切符を不注意で落としてしまい、その切符を他の誰かが拾ったとすると、その他人がその切符を使って電車に乗れてしまうのと同じことです。

一方、国際線の航空券では、航空券を拾っただけでは、他人は飛行機に乗れません。なぜなら、航空券を使用する際、パスポート番号や顔写真の照合などがおこなわれ、その航空券を使用する権利を持つ本人かどうかの確認が行われるからです。

この、国際線の航空券の概念をアクセストークンにも持たせるための仕様の一つとして、『OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens』というものが存在します。まだドラフト段階 (draft-ietf-oauth-mtls) ではありますが、その内容は stable です。この仕様を実装した認可サーバーは既に幾つか存在します。まだ公開していませんが、私の会社の製品 Authlete でも、社内開発ブランチでは実装済みです。この、Mutual TLS の仕様のほかに、Token Binding という仕様も存在します。

Mutual TLS や Token Binding を用いれば、単純にアクセストークンを他の場所に持っていっただけでは利用できなくなるので、よりセキュアになります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/06/12 19:10

    そういうことが知りたかったです。
    「一番分かりやすい OAuth の説明」も併せて、大変ありがとうございました。

    キャンセル

0

上の説明では省略していますが、実際のOAuthにおいては、各クライアントごとにClient Secretという鍵があって、アクセストークンはそれとセットでないと使えません。

Client Secret自体をばらまくようなアプリがあれば、プラットフォーム側、あるいは鍵を無断流用された開発者から、キーを停止されることでしょう。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/11 08:00

    例えば「アプリ+サーバ」という構成のサービスを提供している会社があるとします。
    アプリ側でFacebookやGoogleなどのアカウントを認証しアクセストークンを取得しているとします。
    このアクセストークンとClient Secretをサーバに渡して運用しているような場合、
    これはアウトなのでしょうか。
    同じサービス内だからOKという扱いになるでしょうか。

    キャンセル

  • 2018/05/11 08:19

    アウトかどうかの判定は提供元にしてください。
    そこらへんは日々変動します

    キャンセル

  • 2018/05/11 08:21

    そういうことですか。
    お二方とも、ありがとうございました。

    キャンセル

  • 2018/06/09 02:12

    アクセストークン利用時、Client Secret を併せて提示する必要はありません。Client Secret が使われるのは、Client Type (RFC 6749, 2.1) が Confidential のクライアントアプリケーションが、トークンエンドポイント (RFC 6749, 3.2) にアクセスするときのみです。さらに厳密に言えば、クライアント認証方式が client_secret_basic もしくは client_secret_post (OpenID Connect Core 1.0, 9) の場合のみです。

    キャンセル

関連した質問

同じタグがついた質問を見る

  • Android

    6628questions

    Androidは、Google社が開発したスマートフォンやタブレットなど携帯端末向けのプラットフォームです。 カーネル・ミドルウェア・ユーザーインターフェイス・ウェブブラウザ・電話帳などのアプリケーションやソフトウェアをひとつにまとめて構成。 カーネル・ライブラリ・ランタイムはほとんどがC言語/C++、アプリケーションなどはJavaSEのサブセットとAndroid環境で書かれています。

  • Google

    633questions

    Googleは、アメリカ合衆国に位置する、インターネット関連のサービスや製品を提供している企業です。検索エンジンからアプリケーションの提供まで、多岐にわたるサービスを提供しています。

  • App Store

    154questions

    App Storeは、Apple社が運営する、iPhone、iPod touch、iPad向けアプリケーションソフトのダウンロードサービスです。携帯電話、Wi-Fiによる無線通信に対応しており、多くのアプリケーションをダウンロード、インストールすることができます。世界中の開発者によってアプリケーションが登録されており、有償のソフトもあればフリーソフトも多く登録されています。

  • OAuth

    105questions

    OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。