  |
はてなキーワード: シングルサインオンとは
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
ITエンジニアの業界では資格をとってもなんの意味もないとよく言われる。
あるITエンジニア(インフラ〜バックエンド系)おじさんもその原理主義者のような人でIT系の資格取得をバカにしていた。そんな暇があったら個人開発の一つでもすればいい。資格を持ってるなんてむしろバカをアピールすることだという言いようだった。
しかしある時、おじさんと会話しているとSSO（シングルサインオン）を知らなかった。またある時は、AESが共通鍵暗号の規格だということを知らなかった。どれもAPやベンダー資格の勉強をしてればよく目にするもののはずだ。
最近ツイッターでこのような意見を見かける。それは『マイナンバーカードがもっと普及していれば○○という政策が取れたのに』というものだ。僕はこの意見が間違っていると思う。マイナンバーカードが普及しているかどうかはあまり関係がない。
今の日本の行政の円滑な運営に足りないのは汎用に使える認証・認可基盤である。マイナンバーカードという物質はその手段に過ぎない。認証・認可基盤があれば今やりたいことはだいたいできる。マイナンバーカードを使うかどうかはその時になって考えればいい瑣末な問題である。マイナンバーカードを使う手もあるし使わない手もある。一番大事なのはマイナンバーカードではなくそっちだ。
この誤解は多くの日本人がIT音痴であることの根源に思える。具体的な物体を通さないとその背景のシステムを理解できない。ハードは作れるがソフトを作れない。
Twitterで上記のような主張をする人の中には、プロフィールにITエンジニアと書いている人も多かった。日本人はITエンジニアすらソフトウェアの感覚が乏しいのだ。
僕は昔愛知県内の大手自動車部品メーカーの出入り業者をしていた。この会社の中の人もここを全く理解していなかった。末端社員から偉い人までみんなそうだった。社員・出入り業者・その他関係者向けのシングルサインオンシステムは存在したが、一度認証してしまうとそのシステムに絶大な権限が与えられてしまうので、そのシングルサインオンシステムを使うにはめちゃくちゃ大変な申請が必要だったので、弱小部署が新しく社内向けシステムを作る場合、そのシングルサインオンシステムを使わないことが多く、社員は沢山パスワードを覚えなければならず、各システム担当者は膨大なグループ社員名寄せノウハウを要求されていた。この会社はソフトウェアの時代についていけずに潰れていくんだろうなと思った。（あと未だにLotus Notesつかってるし）
じゃあどうすればいいのか。もちろん認証・認可基盤を作ればいい。ここで、認証と認可は別物である。ITエンジニアすらイマイチ理解していない人が多い。
マイナンバーカードがあればよかったと言ってる人は、マイナンバーカードは認証に使うものなのか認可に使うものなのか教えてほしい。
断っておくと僕はIDの専門家ではない。IDというのは学問的に一大ジャンルなので、細かいことはちゃんと自分でググってほしい。
ざっくり言って、認証が「お前誰よ」で認可が「お前何がしたいん？」である。
GoogleログインやTwitterログインが代表的な例である。あれはOAuthという仕組みだ。Twitterログインを使うと、第三者にTwitterのパスワードを開示しなくても、その人にTwitterに投稿する権限を貸すことができる。その人のことを信用なくなったらTwitterの管理画面からそいつに貸した権限を取り消すことができる。
もし国民OAuthがある状態で、例えば現金の給付がしたいなら末端の官僚さんが国民OAuthシステムに簡単な申請を出し、それから口座入力画面をさっとつくればいい。１日で終わった仕事である。この例であれば、国民OAuthはこの官僚さんに対して「国民の一意性の保証」だけを提供すればいい。それ以外の情報はこの官僚さんが作ったシステムに一切渡らない。そうすれば一人が二回現金を受け取らないシステムが作れる。看護師さんにだけちょっと多めに支払いたいなら、「看護師かどうかフラグ」を提供すればいい。そうすれば、看護師ではない人の職業がバレることもない。そういう柔軟な対応が可能だ。
要するに、安全に様々なシステムを接続できる汎用認証・認可基盤を中心に様々なシステムを連動させていけば新しいシステムを作るのも簡単だし、国民のストレスも少ない。
学部新卒から10年以上お世話になったNTTの事業会社を辞めました。（以下NTTと記載します）
大変お世話になりました。
最近ブームになっている各種NTT退職エントリー（こことかこことか）が出回っている中、どこまで需要があるのか分かりませんが、NTTグループのさらなる発展に向けて少しでも糧になればと思って筆をとってみます。
MPLSや広域イーサネットなどの企業向けネットワークサービスを売る仕事。世間的にはプリセールスエンジニア。
全社を通して、非常にスマートで、理路整然と考えられる人が多く、上司にも恵まれていました。
体育会系という雰囲気もありません。最近、『ラグビー部も職場「乱入」』が話題になっていますが、13年間勤務した限り、そのような場に出くわしたことはありません。仮にそのようなイベントを開催する場合においては、社風から鑑みるに、事前のアナウンスは必ず（少なくとも管理職には）あったはずです。
ラグビーのことは個人的にファンではありませんでした。しかし自社のラグビーチームをチームビルディングなどのイベントで活用するのは、企業として当たり前だと思います。
その時点で業務遂行の能力が不足していたとしても、チャレンジさせてもらえました。
私は帰国子女でもなく、留学、駐在などの経験が全くなく、ほとんど満足に英語が喋れない状態でしたが、希望したグローバルビジネスにチャレンジさせていただけました。その後、日本語を理解しない海外籍上司のもと、世界中の海外籍の方を相手に仕事する経験を長くさせていただきました。結果、TOEICスコアで数百点分英語力が向上しただけではなく、グローバル観点でのビジネスマインドや仕事の仕方を学ぶことが出来て、人間的に大きく成長できたと感じています。
会社や部署、チームとしての役割は当然ありますが、自由に仕事をさせていただきました。
例えば、本来「完成されたサービスを売って売上目標を達成する」ことが目標であるプリセールスでありながら、「目標達成に必要な新サービス開発」や「販売活性化のためのデモ環境整備」などの開発に近い業務もやらせてもらいました。自己成長に繋がり、周囲に認めてもらえたことに、とても感謝しています。
部署・チーム、時期により状況は異なりますが、私の場合、月20時間以下でほぼ収まっていました。そのため、業務後の時間を使って、情報処理技術者試験の上級試験対策や趣味でファイナンシャルプランナーを取得するなど、十分な余力を持つことができました。またプライベートではちょうど子育て期だったのですが、フレックス勤務・リモート勤務などの制度が活用でき、さらに同僚・上司からのサポートや理解が深かったので、仕事と家庭の両方に全力で取り組めました。（子どもを保育園へ送るため、始業時間を30分遅らせたり、子供の病気による突発的な年休取得が出来たり、平日の学校行事へも参加できたり...などなど。）
GAFAに人材流出防げ NTTコムの新キャリアパスなどに代表されるように、NTTの人事・制度は改革の途でありますが、一個人の経験を記録を残したいと思います。
一言で言えば、人事制度に納得できずでモヤモヤしていたところに、やりたい事と方向性が異なる仕事がアサインされたことが決定打になりました。
私が辞めることを決心した時点では管理職になることが唯一のキャリアパスであり、中堅社員にとっては唯一の昇給のプロセスでした（若手のうちは年に5%程度は昇給していたように記憶しています）。当初はそれを当たり前と思ってはいましたが、徐々に現行制度のあり方に疑問をいただくようになりました。
また、上位の職責に上がるためには業績評価とは独立した「選考」があるのですが、周囲の先輩・後輩の選考結果や、自分自身の結果と得られるフィードバックの内容には必ずしも納得はできませんでした（同じ理由である年は通らず、翌年通るなど）。また数ヶ月にわたる選考とその準備のため、毎年疲弊し、100%業務に集中できるとは言い難い状況でした。
初期配属や人事異動といったキャリアパスは入社以来3回は100%希望を聞いていただけていたのですが、4回目でやりたい事とは方向性が全く異なる仕事にアサインされました。
当時私は、「自分が職業人生をかけて実現したいこと」をようやく見つけたところでした。その実現に最も注力したい旬の時期に自社でその活動ができないのは非常に耐え難く感じました。本人の希望とは逆のことをやらせて経験を積ませる育成方法は、かのSteve Jobs氏のConnecting the dotsのようでもあり、私は必ずしても否定するものではありませんが、事前に本人と十分すり合わせをした上で判断されるべきなのだと考えます。（私もタイミング次第では成長の余地として許容したと思います。）
GAFAMではない外資系企業にご縁があり、今はそちらでお世話になっています。外から改めてNTTを見たときに感じることは以下のようなことです。
Job description がない日系企業だからこそ、自分が役に立つと考えたことが自由にできるし、数値以外の観点での評価があるからこそ、評価されうる＝取り組むことができると確信しています。中の人は殻を破ると違う世界が見えてくると思います。
自由に意見が言える、極めて民主的な文化であると思いますが、それ故に「意思決定で様々な関係者の意見を聞きすぎること」「一度決めたことを実施前に声が大きい人が覆せる」などの弊害をあるように思います。それがよく作用する時代もあったのかと思いますが、今のスピード感には合わなくなってきていると感じています。より適切なレベルに意思決定権限を落とすことはもちろん、一度なされた意思決定を全社で尊重する風土になれば、と思って見ています。
また賃金体系や人事評価制度も平等性・一律性が行き過ぎていると感じています。年次・職責を問わず評価に値する人はもっと評価するべきだと思いますし、逆もまた然りだと思います。この点は会社側は改善に動き出したような噂は聞いていますが、労働組合側で前向きに検討しているような噂話が聞こえてこないのは残念でなりません。
PCなどの環境は、生産性に直結します。IT環境の整備は Quality of Work に直結するので、是非投資していただければと思います。（それだけで離職率は下げられると思います。）
など
https://anond.hatelabo.jp/20181129233609
同じくSF在住。いいまとめサンキュ。他に俺が個人的によく使うのは：
ここ1〜2年で急激に伸びてきた電動自転車や電動スクーター（電動のスケボーにハンドルが付いたようなもの）のシェアリングサービス。Birdなど競合も。各スクーターはGPSでトラッキングされていてスマホアプリで近くにあるスクーターを検索できる。使い終わったら乗り捨て。割とそこらじゅうに乗り捨ててあったりする時もあるので街の景観がちょっと変わった感があるが、それを超えて便利。でも乗る場所によっては割と危ない。大きな事故が出てくると規制もありうるかも。（追記：chanmiaさんのブコメによるとすでに規制されて台数が減ってるそうです。指摘感謝です）
日本でも浸透してきてると聞くが、アメリカでも俺の周りだとみんな普通に加入してる感じ。昔のテレビのよう。最近Netflixで何を観た、あれ面白いよね、という会話がもはや日常。逆にAmazon PrimeとかHuluについて同じような会話は俺の周りでは聞かない。テラスハウスとかコンマリとかも周りの人は見てて、日本では本当に男女の恋愛はあんな感じなのかとかの質問を良くされる。俺はドキュメンタリーをよく見る。最近では「Abstract」「Rotten」「Salt Fat Acid Heat」とかが面白かった。「Roma」が良かったと複数の友人から勧められたので今度見る。
代行でレストランの食べ物を取りに行ってデリバリーしてくれるサービス。Seamlessなどの競合も多いしアメリカ国内でも場所によって人気度が違うみたい。東海岸に旅行した時に現地の友達とAirbnbの部屋で宅飲みしようとしてDoorDashで注文しようと言ったら何それ普通Seamlessだべと言われた。結構割高だし、飲み物やサイドオーダーを取ってくるのを忘れるといったちょっとしたミスは割と多いが、払い戻しなどは可。選べるレストランは多い。代行dasherが今どこにいるかの地図表示、予想到着時間、「もうすぐ着きます」メッセージアラートなどがあり、精度はやや甘いが便利。
レストランのリアルタイムオンライン予約サービス。アメリカではこの分野を開拓した存在で、店内の注文管理機能と一体になってるシステムをゴリゴリ営業で納入して加盟店を増やしたという話を昔聞いた。人気口コミサイトのYelpもオンライン予約をサポートするようになったので俺もOpenTableを使う機会はやや減ってきたが、ちょっといい感じのレストランとかの予約にはまだ使うかな。
食料品を代行でショッピングして即日配達してくれるサービス。俺は使ったことないがスーパーの店内ではInstacartのTシャツを着た代行ショッパーを良く見かける。
不動産検索サイト。グーグルマップ感覚で視覚的に使いやすい。住宅の販売物件、賃貸物件の情報が豊富で、間取りや金額そして学区のランクなどいろんな条件で検索できる。Redfinなど競合も多い。売りや貸しに出てない物件でも推定金額が表示される。ズームインしていくと表示中の全ての家という家に金額がマッピング表示されるのはなかなか圧巻。友達のあの人の家の資産価値も分かってしまう！物件の部屋の中などの写真が豊富で、しかも多くはいい感じの家具や内装でいい感じに盛られてる（ステージングといって、これをやる専門業者がいる）ので、見てるだけでも楽しい。ちょっとした脳内バケーションになる。
家具やインテリアのコーディネートのヒントになるプロ撮影写真がカテゴリ別に大量に見れる。ちょっと庶民には無理という写真も多いが、これも脳内バケーションで妄想が膨らんで楽しい。プライスタグのアイコンが付いてる家具は実際に買える。担当したインテリアコーディネーターに連絡することもできる。これでヒントだけ得てPinterestで似たようなIKEAハックを探すのが俺のパターン。
個人間の送金は少なくとも俺の周りだとまだPayPalが強い。数年前にCashとかの他のサービスが出てきて使う人もいたけど俺の周りはPayPalに戻ってる。何が特別便利ということもないが、通常の銀行口座だと個人間の支払は小切手なので（振込はお互いが同じ銀行でないと手数料が高い）、いくら小切手のスキャンと換金が今ではスマホカメラでできるようになったとはいえ、面倒なのはアメリカ人にとっても事実。オンラインショッピングでも支払はクレジットカードかPayPalというところが多い。送金手数料無料のPayPalはもはや第二の銀行口座として定着してる。（追記：vanillayetiさんとchanmiaさんのブコメによるとVenmoの方がイケてるとのこと。指摘感謝です）
手数料無料で株の売買が超簡単にできる。俺は株やったことなかったがちょうどいい入門になってる。Bitcoinに散々振り回されてからRobinhoodに出会い、これでいいじゃんという人が俺を含めて周囲にもチラホラ。
ビジネス向けSNSと良く紹介されるが、転職活動時の職務経歴書としての機能が強い。ハイテク系の会社ではLinkedInページへのリンクを送ればレジュメやCVを提出しなくてもいいというところもある。リクルーターからの連絡や昔の同僚からの誘いなども良く来るが、本気で転職先を探す時はHired.comなど他のサイトも同時に使う。
会社で自分が給料をいくらもらってるか、会社の雰囲気はどうかといった情報を匿名で共有するサービス。職種や役職によって横断的にも検索できる。面接でどんな質問をされたとかの情報も。求人情報も多く、職の大体の給与幅を予想してくれたりする。
ビデオ会議システム。個人ユーザ間だとまだSkypeだったりメッセンジャーの音声通話機能やFaceTimeを使ったりも多いが、会社や仕事だと今はZoomが強い印象。会議室の大型ディスプレイなどとも統合しやすく、支社間や取引先とのZoomビデオ会議に出張先や在宅で仕事してるメンバーも加わってパソコンの画面を共有しながら会議する、みたいな場面は日常的。
カスタマーサービスを問い合わせチケット管理プロセスやFAQ管理システムの統合により効率化した感じのサービスで、自社製品のカスタマーサポートページだけZendeskに飛ばすようにしてる会社も多い。
俺が使ってるというだけで、流行ってるかは全く知らない。ビールサーバを購入して（ただし紹介で加入すると無料）、月額料金を払うと生ビールの小型ケグ(約2リットル)を毎月4つ配達してくれる。地ビールが多く、バリエーションは豊富。軽め、苦め、重めの3つの風味から選ぶ（組み合わせも可）。月額会費分については特定の銘柄のビールを選ぶことはできず選んだ風味でランダムなのが送られてくるが、個別に追加購入する時は指定OK。アメリカは今インディアン・ペールエール(IPA)が大人気で、苦め風味を選ぶとほとんど重複なく次々と初めて見るIPAが送られてくる。どれも美味しい。ビールサーバから注いで飲む冷え冷えのIPA最高です。（追記：会費は毎月約$60です。俺は紹介で加入したのでビールサーバは無料だった）
追記１：
aoiro-cakeさんのブコメで指摘がありましたが確かにこれは外せません。毎年4月15日の夜に駆け込みでTurboTaxのサイトで確定申告する俺。毎回来年こそはもう少し早くやろうって思うんだけどね。
vanillayetiさんのブコメで指摘がありましたが確かに使ってます。支払も画面上のバーコードを会計でスキャンするだけ。ポイントを貯めて無料で飲むラテの美味いこと。アプリであらかじめ注文して並ばずにピックアップできるのも便利。長距離ドライブの休憩ポイントを決めるのにもアプリの店舗検索を良く使います。
追記２：
元増田にJIRAとかがあったのでZendeskとかZoomを入れてみたのだけど、他にもビジネスで使われるサービスは多数でこれが定番とか流行とかは良く知らない。俺の周りだと、会社で使う各種オンラインツールのシングルサインオンはOkta、経費精算はConcur、人事評価プロセスはWorkdayみたいな感じだが、会社によってこのへんは色々な気がするし、今挙げたツールもUIが微妙だったりしてまだ開拓の余地がある感じ。これらの多くのサービスの会社はIPOしていてRobinhoodで買えるので、自分が実際に日常的に使っているツールの使用感とか、今使ってる企業が他のサービスに乗り換えるコストはどうか、将来どう進化しそうかとかを考えて株を買うか決めたりしてる。
シングルサインオンに概念としては近いけど、面白い部分はサーバAに投稿された情報はサーバBにも同期されるって点だね、逆も然り
もしサーバAが落ちていてもサーバBで投稿された情報はサーバAが復帰した時点で同期が始まる
つまりこれまでのSNSはサーバ認証とアカウントが紐付けられていて、アカウントはそれぞれ別人扱いだったけれど、Hubzillaの場合はサーバ認証とアカウントは切り離されているから、アカウントは常に同一人物なんだな
だからTwitterやFacebookのように避難用アカウントとか必要ない
今のところ、なるべくSSOを使わないようにしてる。
パスワードはパスワードマネージャーで１サービスごとに管理してる。
でも最近のSSOの流れに、ホントにこれでいいのか疑問に思ってきた。
だってSSO提供側のTwitterやGoogleに比べれば大抵のサービスの認証は突破しやすいし。
シングルサインオンの名のとおり、SSO提供サービスにログインしてればそのままそのサービスもログインできるんだし。
でも自分のTwitterアカウントを他のサービスに知られるとか嫌なんだよなあ。
あと複数サービスのSSOに対応してる時どれで認証すれば良いのか分からなくなっちゃうし。
みんなどうしてんのかなあ。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
