Web APIの認証方法について

[Hiroaki Kitabatake]

ご無沙汰しております。

北畠です。

いろいろな方に質問しているのですが、

多数の視点からの意見を賜りたく、

こちらにも質問させてください。

質問内容は掲題の通りWeb APIの認証方法についてです。

非公開のサイトにてモニタリングしている数値を、

ユーザ側にて直接取得し、活用してもらうものになります。

その際、URLにユーザIDとパスワードを付加し、

希望の値を取得してもらうことになるかと思うのですが、

取得の度に認証するのか、それともセッションを張っておくのか、

それとも他の方法があるのか、、、何かデファクトスタンダードな方法が

あるのであれば教えていただきたいと思っています。

ちなみに数値の取得にはアクセス制限を設けるつもりです。

判断材料に欠けるものがありましたら、追記いたしますので、

言っていただけたらと思います。

以上、また素人な質問で恐縮ですがよろしくお願いいたします。

[Shumpei Shiraishi]

白石です。

あまり詳しいわけではないので、自分が知っている範囲でお答えしますと。

やっぱり今のデファクトとしては、OAuth2じゃないでしょうか。
標準でもありますので、実装に必要なライブラリも豊富に揃っていますから、導入も簡単です。

他には、HTTPS前提であれば通常のBasic認証も使いやすいかと思います。
ただ、OAuthに比べると柔軟性は下がりますね。

北畠さんのおっしゃっている、「URLにユーザIDとパスワードを付加」はやめておいたほうが良いかと思われます。
URLを見ればパスワードがわかるという状態は絶対に避けるべきでしょう。



2014年1月5日 13:57 Hiroaki Kitabatake <u16...@gmail.com>:

> --
> このメールは Google グループのグループ「html5j」の登録者に送られています。
> このグループから退会し、メールの受信を停止するには、html5-developer...@googlegroups.com
> にメールを送信します。
> このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
> http://groups.google.com/group/html5-developers-jp からこのグループにアクセスしてください。
> その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。



--
++++++++++++
白石俊平（@Shumpei）

株式会社オープンウェブ・テクノロジー代表（http://www.openweb.co.jp ）
HTML5開発者コミュニティ html5j（http://html5j.org ）管理人
Web技術者向け情報メディア HTML5 Experts.jp（http://html5experts.jp ）編集長
読書&共有コミュニティ 読書するエンジニアの会（http://www.bookbookbook.jp）主催

Twitter: http://twitter.com/Shumpei
Facebook: http://www.facebook.com/shumpei.shiraishi
Blog: http://blog.shumpei.net
++++++++++++

[junmt]

こんばんは。松田と申します。

Web API関連はこの数年の間に作ったり使ったりしましたので

コメントさせて頂きます。

現状最もスタンダートと感じているのはOAuth(2.0)です。

最近はSAML認証を見かけるようになりましたが

OAuthとセットでサポートしているパターンが多いので

まだ普及率が低いと考えています。

なお、非公開サイトでイントラ内の通信であると仮定しても

毎回ユーザIDとパスワードを渡すのはユーザーがOKと言っても

普通はやらない方法のためおすすめ出来ません。

※以下は余談になりますが、

　今回非公開サイトとのことですので、もしかしたら該当するかもしれません。

今回の用途から推測しますと、セキュリティの強固さよりもユーザーの

実装しやすさの方が重視した方が良い場合があります。

特にOAuthなどのライブラリが使えないような環境であれば質素に

ユーザー認証後に「アクセストークン」を渡して、APIのメソッドを叩く時は

それを付与してもらうようにするだけで十分だったりします。

ただし、「アクセストークン」の有効期限、手動で無効化する方法など

セキュリティレベルをどこまで上げるか要件定義が必要になります。

（OAuthの他社の実装と比較してどこまでやるか決めるだけですが。。）

また、自作が一番のおすすめという訳ではありませんが、

B to BのWebアプリで時々自作の認証システムを

使っているところを見かけます。

取り留めもなくだらだら文章を書いてしまいましたのが

何かの参考になれば幸いです。

2014年1月5日日曜日 13時57分55秒 UTC+9 a7028:

[Jack]

Jxck と申します。

(自分は ID の専門家ではないので、石を握った方はそっとおろして頂けると幸いです。。)

ちょっと気になったのは、 OAuth は「認証」ではなく「認可」という点です。

という話をうかつ始めると怖い人達に袋叩きに合いそうですが、ここでは肩の力を抜いて行きましょうw

このスレのタイトルに「認証」とあることと、「ユーザIDとパスワードを付加し」とあることから、

本来やりたいことは「認証」という風に読めます。

で、そうすると本来的に権限移譲を目的とした OAuth では実現できません、と怖い人に怒られるパターンだったりします。

その話を置いておいてもっと、現実的に言うと、最終的に知りたいのは以下ですよね。

> 取得の度に認証するのか、それともセッションを張っておくのか、

> それとも他の方法があるのか、、、何かデファクトスタンダードな方法が

> あるのであれば教えていただきたい

わかります。

これは、多分多くの人が思っていて、結構多くの人が独自に実装し、多くの人がそれによりセキュリティ的なリスクを知らずに抱えてしまう場合があります。

なので、デファクトというよりか、「自分が何を確認したくて」「どう制限したいか」によって大きく変わるというのが結論になると思います。

でも、時と場合によって違う、じゃ答えにならにですよね。

もちろん、北畠さんがやりたいことが、 OAuth で過不足無く実現できるという場合もありえます。(プロバイダも自分でやる場合)

でもそうでは無いパターンとしては、 Amazon Web Services の実装が参考になると思います。

AWS は大半の API が課金対象なので、その辺しっかりしているし、皆さんご存知の通りの実績があります。

AWS は REST API を意識しているので、セッションは張りません。 基本毎回コールごとに確認をします。 OAuth でもありません。

で、そっから先の API  は AWS 内のサービスごとにちょっとづつ違ったりします。(変化早いので、嘘言ってたらごめんなさい)

あと、本当に「認証」だけで足りるでしょうか？

S3 はクエスト全体のハッシュ値を付与したりします。

リクエストに不正が無いかを調べるので、これは「認証」でも「認可」でもなく「改竄検知」ですね。

ということで、実は結構考えることが多いし手段も多いし考えきるのは難しいと思うので、

実績があり、自分と同じようなモデルの、同じようなサービスがどうやってるかを見るのが一番かと思います。

AWS は沢山の種類のサービスがあり、基本 REST API があって、参考になるものが多いです。

実装は公開されていませんがドキュメントを読むとどうやっているかはわかります。

他には、認証/認可 があったかはわかりませんが、 API 周りの参考になるリソースとして下記などもあります。

https://apigee.com/

ご参考になれば。

Jxck

[Taketoshi Yagishita]

> 非公開のサイトにてモニタリングしている数値を、
> ユーザ側にて直接取得し、活用してもらうものになります。
既にいわれているように、OAuth 2.0 を利用して情報を取得するという方法はあります。
あくまでも許可したユーザに対してデータを提供するということであれば。

> ちなみに数値の取得にはアクセス制限を設けるつもりです。
ユーザ A と ユーザ B で、取得できるデータの種別が異なるのであれば、何らかの会員管理みたいなものが必要ではないでしょうか。
そうであるならば、Movable Type や WordPress を利用するのもありだと思います。
Movable Type や WordPress ならば、パスワードリマインダをはじめに基本機能が実装されていますし、Perl や PHP
等を利用してプラグインを開発することで、機能を強化できますね。

> 取得の度に認証するのか、それともセッションを張っておくのか、
> それとも他の方法があるのか、、、何かデファクトスタンダードな方法が
> あるのであれば教えていただきたいと思っています。

有効期限を設定したセッション管理が一般的だと思います。
--
Taketoshi Yagishita <taket...@gmail.com>

[Hiroaki Kitabatake]

北畠です。

皆様、返信ありがとうございます。

OAuthについては調べてみたり、

他の方からも出てきましたが、

今回は非公開のサイトを利用しているユーザへの提供(Web API)となるため、

OAuthのメリットを活かせないのでは、と思っています。

また、OAuthについては今の「標準」ではなく、「流行り」だったりするのでしょうか？

標準でなければ標準となるまでは実装の検討を控えたいと考えています。

(ただ、OAuthについて理解しているわけではありませんので、メリットを履き違えているかもしれません。。)

追記になりますが、通信はhttpsとなります。

このことから、白石さんが絶対に避けるべきと仰る「URLにユーザIDとパスワードを付加」

してもセキュリティ的に問題はなさそうな気もしますが、

他の理由があったりするでしょうか？

ちなみに、非公開サイトへのログインID・パスワードと同一のもので認証することを想定しており、

基本的にURLに付加するパターンしかイメージできていません。。。

また、RESTfullでの実装を考えてはいるのですが、

松田さんの仰る

> ユーザー認証後に「アクセストークン」を渡して、APIのメソッドを叩く

や、Yagishitaさんが仰る

> 有効期限を設定したセッション管理

という方式の場合のメリットはどのようなものになるでしょうか？

(無知ですみません。。)

Jxckさんの仰るプロバイダとはAPIの提供になるでしょうか？

AWSについては調査してみます。

情報提供ありがとうございます。

更に追記ですが、取得できるデータの種別はユーザ毎に違いがないようにするつもりで、

実装は標準的でシンプルなものが理想です。

以上、よろしくお願いいたします。

2014年1月6日 11:37 Taketoshi Yagishita <taket...@gmail.com>:

[Shumpei Shiraishi]

白石です。

OAuthはIETFの仕様になってますね。
http://tools.ietf.org/html/rfc6749

あと、

> 追記になりますが、通信はhttpsとなります。
> このことから、白石さんが絶対に避けるべきと仰る「URLにユーザIDとパスワードを付加」
> してもセキュリティ的に問題はなさそうな気もしますが、

言われてみれば、https通信上であればURLも暗号化されるんですね。そこまでは思い至りませんでした・・
であれば、https上であれば、Basic認証とセキュリティ強度は同程度になる？なんかそうでもない気がしますが・・
ぼく、セキュリティの専門家じゃないので、あとは詳しい人にお任せします。。。





2014年1月7日 12:00 Hiroaki Kitabatake <u16...@gmail.com>:

[Futomi Hatano]

羽田野です。

> > 追記になりますが、通信はhttpsとなります。
> > このことから、白石さんが絶対に避けるべきと仰る「URLにユーザIDとパスワードを付加」
> > してもセキュリティ的に問題はなさそうな気もしますが、

サーバーのログにプレーンで残ってしまいます。
もちろん、これが漏洩する可能性は低いかもしれませんが、
パスワードまでプレーンでサーバーに残ってしまうというのは
個人的には気が引けますねぇ。
もしサーバーがクラックされたらアウトですから。

どうしてもURLにくっつけて送りたいなら、ユーザーIDとパスワードと
+アルファ（時間など）を結合して何かしらの暗号化を施した上で送るのが
ベストでしょうが、JavaScriptベースだと厳しいですね。
Web Cryptography APIがもっと普及すれば可能かもしれませんが。
http://www.w3.org/TR/WebCryptoAPI/

個人的には、IDとパスワードの送信は、GETではなく、せめてPOSTに
したほうが良いと思いますねぇ。
もっというと、パスワードはやはり送らないほうが良くて、
何かしらのAPIキーを発行するなりして、それを認証に使うほうが
良い気がします。
とはいえ、そのパスワードがどれほどの意味を持つものなのかは
サービスに依存するのでなんとも言えませんが、もし、そのIDと
パスワードが、何かしらの会員管理や課金管理にも使われるものならば、
やはりGETで送るのは避けるべきではないでしょうかね。

すみません。私もセキュリティーの専門家ではないので、
これでいいのかどうか、自身はないのですが :)

Futomi Hatano
http://www.html5.jp/
http://www.futomi.com/
http://twitter.com/futomi

[Y.Nishimura]

こんにちわ。西村です。

初めて投稿する気がします。

話がぐちゃっとしてるような気がするので、整理してみてはいかがでしょう。

北畠さんの話を解釈すると、

* 既存、非公開のモニタリングを行っているサイトＡがある
* サイトＡは既にユーザＩＤとパスワードによる認証によって、
ユーザに対してブラウザでデータを提供している（？たぶん）
* 今回、この提供データをサイトＡの画面ではなく、
（ＲＥＳＴ的な）APIにて取得可能にしたい
* このデータはユーザ毎に取得可能な値が違うので、
認証、または認可によって制限をかけたい

ということなのかと思います。

なので、北畠さんは、このAPIに認証ないし認可を与えるにあたり、
既存サイトＡのＩＤとパスワードを使用してWEB APIを制御しようと考えており、
その方法論について質問している、と認識しました。

そしてたぶん、北畠さんは、OAuthの認識について、FBやTWのような外部プロバイダ
による認可を考えていて、今回の要件にはメリットがあまりない、
と感じていらっしゃるのではないでしょうか。

OAuthの最初の側面は、外部プロバイダによるユーザの認証認可とAPIの利用、ですが、
今回回答してもらっているものは、次の側面、自身が（サイトＡが）
外部プロバイダと同義になって、APIを提供する、ということだと思います。
（サイトＡにあるＩＤとパスワードでOAuth認証し、APIに対する認可を与えることで、
やりたいことであるデータの提供についてRESTな感じのAPIを提供可能になります）

ここの認識があえば、解答的にはそんなに難しい話ではなくて、

* IDとパスワードを都度ネットワークに流すのはHTTPSであっても
あまり感心したやり方ではありません
* OAuth は既に標準仕様です
* サイトＡをOAuthプロバイダにすることが可能なら、仕掛け的にはそれがもっとも標準的です。（たぶん）
OAuth Server 等で検索すると、言語毎の実装サンプルは多彩です。
* それが認証システムの再実装に感じられて既存資産を活かせないとお考えなら、
通常のWEBサービスのふりをしたREST Responseを返却するAPIを組み立てる、
というのが現実解のような気がします。

ここでひとつ懸念があるとすれば、

> ちなみに、非公開サイトへのログインID・パスワードと同一のもので認証することを想定しており、
> 基本的にURLに付加するパターンしかイメージできていません。。。

既存のサイトＡのリクエストが、ログインＩＤとパスワードを常に引き回しているような
作りの場合は、そもそも論としてサイトＡの見直しを勧めたい、ということくらいでしょうか。


長くなってしまいましたが、うまく整理できているでしょうか？



2014年1月7日 12:51 Futomi Hatano <futomi...@gmail.com>:

[junmt]

松田です。

すみません。古いJavaのシステムばかり相手をしているので、私の回答はちょっとずれちゃってますね。

> ユーザー認証後に「アクセストークン」を渡して、APIのメソッドを叩く

これのメリットとしては、
- OAuthなどのライブラリの組み込みが難しい場合、比較的簡単に組める
- 検証範囲が狭い
- 特別な知識がなくてもユーザーに仕様説明が簡単に出来る(学習コストゼロ)

ぐらいで、これと言ったものはないです。

デメリットは
- オレオレフレームワークになるので、設計書や仕様書を残しておかないと後で酷いことになるかも
- 後でなんで一般的な方法を取らなかったのか？と責められる可能性がある

ということで、事例の一つぐらいに捉えていただければと。。

[Shinichiroh Takezaki [Virtual Technology]]

こんにちは。竹嵜と申します。

私もWebAPIの認証でいろいろ悩んできました。

セキュリティの専門家ではありませんが今は以下のような感じで考えています。

•  APIの認証システムが単独であれば都度認証する方法もありだと思います。ですが、このAPI以外にログイン認証を伴うポータルサイトなどがある場合に話がややこしくなると思います。
• 認証が複数存在する場合は安全なシングルサインオンを考えないといけないので、OAuth2.0を素直に使うのがベストだと思います。
• APIの認証システムが単独である場合は都度認証するか、複数回実行になるのであればセッションを使うようにするとユーザビリティはよくなります。（生パスワードを流さなければどちらもセキュリティ的には大差ないように思います）
• やってはいけないと思われるのは、生パスワードを保存しておいて、他のシステムの認証にも使ってしまうようなことです。
• また通信に生パスワードが流れるのはSSLで暗号化していてもログに書かれてしまうことを嫌悪する人も多いと思います。私もそうなので、Basic認証は使わずにDigest認証やWSSEのようにパスワードをハッシュ化して送信するようにしています。システムではこれをさらにハッシュ化したものを保存し、生パスワードは保存しません。
• こうすると他のシステムの認証のために保存したパスワードを利用することができなくなりますが、むしろユーザに対しての安心感は増すと思います（そもそも生パスワードを知らないわけですから漏れることも悪用（再利用）されることもないという意味で）

2014年1月7日 23:09 junmt <jun...@gmail.com>:

--
このメールは Google グループのグループ「html5j」の登録者に送られています。
このグループから退会し、メールの受信を停止するには、html5-developer...@googlegroups.com にメールを送信します。
このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
http://groups.google.com/group/html5-developers-jp からこのグループにアクセスしてください。
その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。

--
 _/ 有限会社バーチャルテクノロジー　竹嵜 伸一郎
 _/　 Virtual Technology, Ready to Cloud
 _/ http://www.virtual-tech.net/

[Hiroaki Kitabatake]

北畠です。

皆さんのお陰で、大分スッキリしてきました。

ありがとうございます。

まず、西村さんがまさしくその通りで、

言いたいことをわかりやすく書いてくださり、

感謝いたします。

(ちなみに、懸念事項のような作りとはなっておらず、

ID・パスワードはサイトへのログイン時にしか使用していません。)

そんな現状をを踏まえまして、皆さんの意見をまとめますと、、

サーバにログがプレーンな状態で残ってしまうことは避けるべき。

そのため、httpsだろうがURLにそのままサイトAで利用しているID・パスワードを使用するのはダメ。

ということで、もしこの形で実装するなら、アクセスキーを発行して、利用してもらう方法を取る。

(セッションを張るとセッション情報を何らかの形で保持しなければならないため、

アクセス毎に認証するような形にしたい。)

実装(利用側・提供側)に無理・手間がなければOAuthを利用する。

標準ということで、可能な限りこちらを利用したい。(個人的見解)

そもそも実装方法やサイトAをプロバイダにする？等についてまだ理解していないため、

調べる必要がある。

ということになるかと思います。

最後にOAuthについて理解していないため、何とも言えませんが、

松田さんが仰っている

> - 特別な知識がなくてもユーザーに仕様説明が簡単に出来る(学習コストゼロ)

と言うのは大きなアドバンテージに思えるのですがいかがでしょうか？

また、竹嵜さんが仰っている

> - 複数回実行になるのであればセッションを使うようにするとユーザビリティはよくなります。

についてですが、複数回実行時のセッションの利用によってユーザビリティが向上するとは、

どういう定義の場合にどういった部分でそうなるのでしょうか？

いずれにしろ、導入までまだ少し時間がありますので、

もう少し調べてみたいと思います。

お力添えありがとうございました。

他にもアドバイスや解釈が間違っている等ありましたら引き続きよろしくお願いいたします。

以上

2014年1月8日 0:58 Shinichiroh Takezaki [Virtual Technology] <take...@virtual-tech.net>:

[Shinichiroh Takezaki [Virtual Technology]]

竹嵜です。

 セッションを利用する方がユーザビリティが上がるというのは、セッション管理によりログイン状態を作ることで、ユーザに毎回userid/passwordを入れさせないで済むという意味です。APIの場合、ブラウザのログインフォームのようにuserid/passwordを記憶させることは困難だと思います。ハードコードすればいいのですがいろいろ問題があります。

 Google Data APIには以前、Client Login方式 (https://developers.google.com/accounts/docs/AuthForInstalledApps)というのがありましたが今は廃止されてOAuth2.0に移行しています。

 かつてのClientLogin方式はuserid/password認証ができて便利でしたが、しばしばCAPTCHAロックが発生するため、アプリで（userid/password固定で）使うのは困難でした。Googleは不正ログイン対策のためにuserid/password方式を諦めたんだと思います。

 APIの認証ではアプリ固有のキーを発行する方法が一番フィットするのかもしれません。

 GoogleのClientLoginもOAuth2.0移行までのworkaroundとして、アプリケーション固有のパスワードを生成して使用する方法(https://support.google.com/a/answer/1032419)が用意されています。

 BaaSで有名なParse.comは管理画面でREST用のキーペア（X-Parse-Application-IdとX-Parse-REST-API-Key）を発行します。しかし、あくまでアプリ認証なのでユーザ管理は別途必要です。 http://blog.parse.com/2012/01/19/javascript-and-user-authentication-for-the-rest-api/

あと、ブラウザからAPIを使ってログインする場合にはCSRF対策も考える必要があります。

http://matome.naver.jp/odai/2133794394551702001

http://utf-8.jp/public/20131114/owasp.pptx の P24-25に対策があります。

 DropboxUploaderは(https://github.com/andreafabrizi/Dropbox-Uploader)はbashでOAuth2.0を使っています。しかし実際に導入してみるとわかるのですがOAuth2.0の設定が面倒くさいです。

OAuth2.0はちょっと大掛かり過ぎなので、個人的には、管理画面からAPIkeyを発行して、APIkey+userid+password(digest)で認証する方法がいいかなと思っています。でもこれは所謂オレオレAPIセキュリティですので責任は持てません。snapchatの事件(http://www.thread-safe.com/2014/01/46m-usernames-phone-numbers-leaked-by.html) もあったばかりなので慎重に考えていきたいところです。セキュリティ屋さんからも叩かれそうですし。

2014年1月8日 12:00 Hiroaki Kitabatake <u16...@gmail.com>:

[Hiroaki Kitabatake]

北畠です。

竹崎さん

回答ただきありがとうございます。

また、いろいろ情報提供くださり、助かります。

ちょっと理解力がなくて申し訳ありませんが、

セッションを利用する方がユーザビリティが上がるというのは、セッション管理によりログイン状態を作ることで、ユーザに毎回userid/passwordを入れさせないで済むという意味です。

とはログインフォームによる認証が前提なのでしょうか？

もしかしてOAuthも？

とにかくまだ調べる(勉強する)ことができていない状態で

質問ばかりするのも大変失礼かと思いますので、

まずはOAuth周りから時間を見つけて調べていみたいと思います。

以上

2014年1月8日 23:29 Shinichiroh Takezaki [Virtual Technology] <take...@virtual-tech.net>:

[Shinichiroh Takezaki [Virtual Technology]]

竹嵜です。

セッションIDは、ログインフォームによる認証が前提で、正規のログイン画面で認証した後で入手することになります。

アプリ固有のキーを使う場合も、管理画面にログインした後でキーをコピペしますので同じ意味になると思います。このような方法であれば安全なんでしょう。

ログインフォームによる認証ではなく、APIによる認証も欲しいところですが、これはどう実現するかが悩みどころです。

GoogleのClientLoginの件もしかり、昔流行ったWSSEにしても、 https://www.google.co.jp/search?q=WSSE で検索してもわかるように、ほとんどのサービスがOAuth2.0に移行している現状があります。WSSEはリピート攻撃に弱く、筋が悪いと言われていることや、Webの認証機能に一元化したいという背景があるようです。

ちなみに、OAuth2.0ではアクセストークンを入手する際に最低一回は必ず、正規のWebのログイン画面で認証する必要があります。OAuth2.0を使うということは、つまり、認証はAPIでは行わないことと同意なわけです。（OAuthは認可であるということ）

個人的には、オレオレAPIセキュリティで十分という立場ですが、(( ；゜Д゜)) ガクブルですね。

2014年1月10日 11:22 Hiroaki Kitabatake <u16...@gmail.com>:

[Ryo HAYASHI]

林と申します。

OAuth は認可ですが非公開な API であるならば静的なアクセストークンを予め発行しちゃってもいいんじゃないでしょうか。
話題に上がってるオレオレなんとか？なんかと大差ないかもしれませんがパブリックな仕様なので実装面でメリットがあるかと思います。
また、運用によると思いますが IP アドレスや UA
を拾っておけば胡散臭いやつもキャッチアップできますし、それを元に対処療法的に対応するんでも十分フォロー可能かと思います。

OAuth 2.0 も面倒ですけど OAuth 2.0 Bearer ならば Basic 認証とあんまり変わらないです。
参考になるかどうかわからないですけど、パブリックな仕様の必要ないところだけ省略するってのが諸々楽なんじゃないかと。

よろしくどうぞ。

2014年1月10日 13:25 Shinichiroh Takezaki [Virtual Technology]

[Shinichiroh Takezaki [Virtual Technology]]

竹嵜です。

林さん、フォローありがとうございます。

おっしゃるように、アクセストークンを予め取得する方法で、ほとんどの運用はできると思います。また、（私は知りませんでしたが）Bearerについても

Authorizationヘッダに"Bearer " + アクセストークン

でAPI実行時のヘッダに付ければいけるようです。

ただ１点だけ。この場合は認証ではなく認可の一部ですね。

「アクセストークンを予め取得する」ときが認証になると思います。

（なので、API実行時にはアクセストークンの検証はしますが認証はしないことに注意です。細かい話ですが・・・）

2014年1月10日 16:39 Ryo HAYASHI <ryo...@gmail.com>:

[Ryo HAYASHI]

林です。

> ただ１点だけ。この場合は認証ではなく認可の一部ですね。

そうすね。そこらへんは Bearer の仕様を見ていただければ例外の種別なんかでもって類推可能なんで説明省略してます。
と言うか OAuth のどこを見ても認証を実装するための仕様は無いので杞憂っぽい気も。すみません藪蛇だったら。

2014年1月10日 16:58 Shinichiroh Takezaki [Virtual Technology]

[Shinichiroh Takezaki [Virtual Technology]]

竹嵜です。

これまでの議論を自分の観点でまとめてみました。

http://blog.virtual-tech.net/2014/01/web-api.html

次回のHTML5とか勉強会もセキュリティのようで、楽しみにしております。

2014年1月10日 17:10 Ryo HAYASHI <ryo...@gmail.com>:

[Shinichiroh Takezaki [Virtual Technology]]

竹嵜です。

@ritouさんから教えていただいたのですが、OAuthのResource Owner Password Credentials
というのがあるそうです。 ID/PW認証をAPIでやりたいときに使えます。

例えば、このようなリクエストをOAuth Providerに投げると、
{
"grant_type" : "password",
"username" : "us...@example.com",
"password" : "sekret",
"client_id" : "the_client_id",
"client_secret" : "the_client_secret"
}

以下のように、access_tokenが返ってくるので、
{
"access_token":
"1f0af717251950dbd4d73154fdf0a474a5c5119adad999683f5b450c460726aa",
"token_type": "bearer",
"expires_in": 7200
}

あとは、Authorizationヘッダに"Bearer " + access_token
をAPI実行時のヘッダに付ければいけます。

http://blog.virtual-tech.net/2014/01/web-api.html に追記しておきました。

2014年1月14日 18:22 Shinichiroh Takezaki [Virtual Technology]

[Hiroaki Kitabatake]

北畠です。

竹嵜さん、林さん

ご返信が遅れまして大変失礼いたしました。

林さんが仰っているような

キーの発行を代行し、直接ユーザにキーを提供して使用してもらう

ということを行えば、

ユーザにログインしてもらうことや、

キーを発行するための本Webサイトへの実装の追加も

いらなくなるということになるでしょうか。

竹嵜さん、まとめありがとうございます。

読みました。

特にログインフォームなどのセキュリティ強化策については、

確かにこっちのセキュリティはどうなのだろうと、

単純に疑問が湧いてきました。

以下については知識がありませんが、

Bearerとは、OAuthにて

認証済みのキーを利用して認可してもらうためのものでしょうか？

(つまり、最初に記述した「キーの発行を代行し、直接ユーザにキーを提供して使用してもらう」ためのこと？)

Resource Owner Password Credentialsについて

こちらも最初に記述したキーの代理発行を

APIで実現するものになるでしょうか？

見当違いでしたらすみません。。

2014年1月16日 22:23 Shinichiroh Takezaki [Virtual Technology] <take...@virtual-tech.net>:

[Shinichiroh Takezaki [Virtual Technology]]

竹嵜です。

Resource Owner Password CredentialsとOAuth Bearerについては、私も詳しくはないのですが、だいたいこんな感じです。
まず、「キーの発行を代行し、直接ユーザにキーを提供して使用してもらう」
ために、Resource Owner Password
Credentialsを使って、ユーザID/PWを含めて送信することでAccessToken
を取得します。このAccessTokenが認証済みのキーですね。

あとはAccessTokenをヘッダに付けてリクエストすればいいだけです。
その方法がOAuth Bearerになります。

以下のritouさんの記事（Apache Usergrid）が参考になると思います。
http://qiita.com/ritou/items/0cd4b4a1750ec854b588

Applicationとユーザーの作成で、まず「Resource Owner Password
Credentials」を使ってAccessTokenを取得し、次に、「OAuth
Bearer」でApplication用のユーザーを作成しています。

ただ、個人的には、Resource Owner Password Credentialsでも、パスワードが生で送信されるためあまり好きにはなれません。

2014年1月27日 16:08 Hiroaki Kitabatake <u16...@gmail.com>:

[Hiroaki Kitabatake]

北畠です。

竹嵜さん

質問しておいて返事ができず大変失礼いたしました。

また、毎回丁寧に回答していただきありがとうございます。

少し間があいてしまいましたので、どこかで時間を見つけて

これまでのことを自分なりに整理してみたいと思います。

何か疑問やわからないことがあった時にはまたこちらに

質問させていただきたいと思いますので、

よろしくお願いいたします。

みなさんお忙しい中、本当にありがとうございました。