  |
はてなキーワード: Google Appsとは
[B! AI] AIのやりすぎで頭がおかしくなっている - 運河
それはAI依存症だ。アルコールやたばこと一緒。そして自分も依存を感じている。
自分と元増田との違いを挙げれば、彼が生粋のエンジニアであり自らコーディングができる人であるのに対し、私はコーディングの技術を身につけたいと願い、その作業に楽しさを感じてはいるものの、職業としてプログラミングをする立場ではないということだ。
仕事としてはデザイン領域がメインであり、IT業界の端くれのような存在である。始まりはBASIC。社会人になって業務改善のためにPHPやPerlのコードを書いたり、ExcelのマクロやGoogle Apps Scriptの作成、Webサーバー立ち上げてPHPやPythonのスクリプト動かして周囲が使えるツールを作るなど、地味に「コーディングできるひと」のポジションではあった。
ある程度プログラミングができる人なら、プログラムを作ることで物事をつなげて、何かしらのアウトプットが得られる、という絵がかけるはず。プログラム書けば、この作業ものすごく効率的になるんじゃね？ ここ繋げれば解決しちゃうんじゃね？ こういうアプリがあればいいのにねー、的なアイデアを数多く持っていた。しかし、プログラミングに没頭するだけの余裕も機会も、そして十分なスキルも持ち合わせていなかった。この仕事たるいなー、効率悪いなー、でもこの問題を解決できるほどのすばらしいコード書けるわけじゃないし、みたいな状況。コード書くわけじゃなく、タルい仕事を人力で解決してきた。
それが今や、AIに話しかければプログラムの断片を書いてくれるようになり、気がつけば空っぽのフォルダを指定して「こういう機能が欲しい、仕様はこうだ」と想像したことを伝えるだけで、その機能をどのような技術で実装できるかを検討し、本当に動くものが出来上がってしまう。かつての「ここはプログラムで対応できるはずなのに、自分がそんなプログラムかけないし、プログラム書こうとして数日費やすよりも、人力で対応しなきゃだな...」という壁が、突然ポカンと消え去ったのだ。次々と目の前の問題が解決されていくのは、快感でしかない。
自分が「これは中毒だな」と確信したのは、AIへの課金が重なってきたタイミングだった。最初はAIにお金を払うべきかどうかの判断すら曖昧だったが、とにかく触れてみようということで、Notion AIを使い始めた。しかし、こちらはどう活用できるのかがピンとこず、自分のスタイルにはフィットしなかった。
そうこうしている間にChatGPTが大流行。ChatGPTは深掘りすればするほど賢い答えを返してくる。ChatGPTはコードが書ける、というところまできて、実際にコードを書かせ始めたら、そこが沼の入口だった。
コード書かせ始めると、すぐに無料枠の利用上限が来てしまう。半日待て、と言われて、そんなもん待てるか、という欲求から課金が始まった。そしてコードの断片を書かせてエディタにコピペするコーディングを楽しんできた。まだ自分が統率して自分の能力でコーディングをしている世界。自分が介在しないと、コードはあってもそれを動かせる状況にならない。まだ自分が王様である。
次第に「コードをコピペしてファイルを作り、コンソールに戻って実行する」という一連の作業が厄介に感じ始めていた。他の人ってこういうことやってるよね？と調べてみると、自分の使い方は1年前のそれだということがわかった。現在、世の中は「自律型AI」だとかAIエージェントだとか、AIコードエディターとか、まったく別の次元に来ていた。例えば「在庫管理をしたい。項目はこれ、入力・閲覧・管理画面、そして月一度の棚卸し画面をすべて実装してほしい」と伝えるだけで、それらをまるっとウェブアプリとして実装してしまうのが今の状況だ。フォルダの中に情報を集約し、その中身をすべてAIに任せ、PCのコマンド操作までAIに指示を出すというものだ。すると、AIがフォルダ内で縦横無尽に動き回り、大量のファイルやコードを生成して、必要な構成をすべて作り上げてくれる。もはや初期に作っていたスクリプトとは規模が全く違う。
AIに関する最新情報を自分で取りに行かないと、最近はどういう使い方ができるようになった、みたいなのを拾えないのも、AIの特徴。しばらくChatGPTにコード書かせて「AIすげー」ってなってたけど、それ以上をまったく知らず。この劇的な変化は、自分で触っていないとついていけなくなる。どうも、常に新しいものがでてきて、価値観がバキバキと転換されている。そこに追従していっている人達がいる。なんだかすげえ、もっと知りたい、もっと使いこなしたい、使えている俺かっけー、おいていかれたくない、ふみとどまりたい、みたいな気持ち。
新しいツールを見つけるととりあえず試し、よさそうだな、自分の生活変わりそうだな、何か可能性を感じる、そんな兆しがあれば課金勢になる。具体的な中毒症状は「課金」という形で如実に表れている。AIに月2、3万円使っていると言えば、かつてのソーシャルゲームへの重課金と同じレベルの話だと、理解してもらえるのではないだろうか。
かつてインターネットにハマって電話代で死んだ人たちがテレホーダイで助かり、それでも世の中に浸透して常時接続があたりまえになったように、平等にAIは使えるようになっていくだろう。ソシャゲ勢が阿鼻叫喚する中、ガチャが法律で制限されたように、AI課金もそのうちピークを迎えて、制限されるようになるんじゃないかなあ。そして手ぐすね引いて待ち構える広告業界。AI広告まじ怖いね。
昨年の11月で一般就労して3年経った。私は10代の頃に統合失調症と診断され、さらに30代半ばで知能検査を受けたところADHDグレーゾーンとの主治医の判断から発達障害の薬も処方されている。
入社当初は週20時間のパートで、徐々に勤務時間を増やし、昨年の2月からは正社員になった。現在は42歳だが、常時フルタイムで働くのは初めて。一人暮らしのため家事もこなす必要があるものの、いまのところ順調に生活できている。仕事終わりには平日でも出かけることがあり、休日も大抵は遊びに行くくらいだ。
業務内容は典型的なオフィスワーク。苦手な分野(電話ほか)は障害者雇用ということで配慮してもらっている。昔からコンピュータには親しんでいるタイプで、Google Apps Script などプログラミングも多少は扱えるため自分一人で担当している業務も多い。ありがたいことだ。これほど真っ当に仕事ができたことは今までなかった。
しかし、最近では不満もいくつか出てきた。その一つは、業務が属人化しているのに誰もその状況を打開しようとしないこと。自分一人で担当している業務があるというのは、まさにそれ。各種業務のマニュアルを整備する、各自の苦手分野を克服するために研修を開くよう訴えるなどしても現時点では何も変わっていない。
こうした訴えが気に入らないのは理解できる。障害者雇用で働いてる奴が偉そうな口をきくな、と思われても不思議ではない。人間関係も悪くはなかったとは思う(飲み会にもたびたび誘われていた)が、最近は孤立気味だ。
結局のところ、私のような障害者の行く末は多数派である健常者の「お気持ち」によって左右されるのだ。健常者であっても合理的で首尾一貫している人物は稀で、不快な印象を与えた途端に手のひらを返される。効率を求めるはずの職場で、効率を上げるための訴えが通用しない不条理。これこそが障害者の末路だ。世間には「統合失調症患者の発言は支離滅裂」と言われ、必死に努力を重ねてきた結果がこれ。やりきれない。
ちなみに、自分だけが担当している業務のうちいくつかはマニュアルを作ったもののフィードバックは無し。もしもマニュアルの出来が悪いならそう伝えれば良い、というよりそう伝える「べき」だろう。
まあ、孤立気味なのは別の理由がある可能性もある。誰かから事情を聞いたわけでもないので本当のところはわからないし、ただ被害妄想に陥っているのかも。今日11:00前に投げたSlackに対して終日返信が無かったのは事実で、たびたびこういうことはあるが。
ここに書いた内容にも「統合失調症患者の妄想」だの色々と言われるだろう。”統合失調症患者の発言であれば妄想である”という命題が成り立つのであれば証明してほしいところだが、多数派であるだけが取り柄の健常者には難しいかもしれない。
検索式を書きますので、それで見つかったファイルを全て選択して、削除などのアクションをしてください。
細かな調整は各自のお好みで変更してください。
◆1年以上前のファイルサイズの大きなメール（300kB以上)を検索（星を付けたメールは除く）。削除しましょう。
older_than:1y larger:300k -is:starred
◆プロモーションやソーシャルに分類された1か月以上前のメールを検索。削除しましょう
(category:promotions OR category:social) older_than:30d
◆受信トレイの180日以上前のメールを検索。アーカイブして、受信トレイのメール数を減らしましょう
label:inbox older_than:180d
◆プロモーションやソーシャルに入ったメールで2日経ったものを検索。既読にしましょう。
label:inbox (category:promotions OR category:social) older_than:2d
Google Apps Script（GAS)を使うとこれを毎日自動で行ってもらえます。
実行の左のアイコンで保存。関数をcleanUpGmailを選んで実行。初回は権限確認のメッセージが出るのでOKを押してください。
無事実行出来たら一番の難関はクリアです。これを毎日自動で実行してもらいましょう。一度に250通が処理されます。
また余裕があれば、左上の無題のプロジェクトになっているところの名前を「gmail自動処理」などに変更しても良いでしょう。
実行する関数：CleanUpGmail デプロイ：Head イベント：時間主導 時間べース：時間ベース 時間の間隔：6時間おき
これで1日に4回、合計1000通が自動処理されますので、たくさんメールが溜まっている方でも、1か月程度で全て処理されると思います。
function cleanUpGmail() { // メインの関数の開始ログ console.log("=== cleanUpGmail start ==="); // 1) 2年以上前 & 300KB以上 & from:gmail.comではない & スター付きではない → 削除 console.log("古い大きなメールは削除"); processThreads("older_than:2y larger:300k -from:gmail.com -is:starred", "trash"); // 2) プロモーション or ソーシャル & 30日以上前 → 削除 console.log("プロモーションとソーシャルは1か月で削除"); processThreads("(category:promotions OR category:social) older_than:30d", "trash"); // 3) 受信トレイ & 180日以上前 → アーカイブ console.log("受信トレイの180日以上前 → アーカイブ"); processThreads("label:inbox older_than:180d", "archive"); // 4) 受信トレイ & プロモーション or ソーシャル & 2日以上前 → 既読 console.log("受信トレイでプロモーション or ソーシャル かつ 2日以上前 → 既読"); processThreads("label:inbox (category:promotions OR category:social) older_than:2d", "markRead"); console.log("=== cleanUpGmail end ==="); } function processThreads(query, action) { // 1回あたり250件だけ処理 var batchSize = 250; // 最初の 250 件のみ取得 var threads = GmailApp.search(query, 0, batchSize); var count = threads.length; Logger.log("検索クエリ: [" + query + "] | 取得スレッド数: " + count); // スレッドごとにアクションを実行 threads.forEach(function(thread) { switch (action) { case "trash": thread.moveToTrash(); break; case "archive": thread.moveToArchive(); break; case "markRead": thread.markRead(); break; default: Logger.log("不明なアクション: " + action); } }); Logger.log("処理したスレッド数: " + count); }
今さらな気しかしないけど、実際どうなんだってことで試してみることにした。
一連の騒動でbotって禁止されたり、課金しないとダメになったのかと思ったけど、どうやらそういことはないらしい。
プログラミングは未経験だけどGoogle Apps Scriptでコードを入れてアカウントを作って、botでポストするまでは仕上がった。
サーバを用意しなきゃいけないものだと思ってたけど、そういうのが必要なく形になったから面白い。
内容はざっくりと言うと、天気予報を自動で取得して、ポストするbotだ。
最初に思いついた計画はアフィリンクを垂れ流すアカを作りたかったけど、とりあえず第一弾ってことで。
これでインプを稼いで、収益化や！と意気込んでいたけど、そうはいかない。
稼働して形にはなってるから、これからは調整と追加を行っていくフェーズに進んだとは思う。
ただ、先行きは怪しいな。
あとは、アイデア勝負で他のネタのbotを考え続けて、当たるまで続けるとか。
プログラミングの経験値を積めましたって話で面白かったってとこはあるけど。
フツーにAIによる業務効率で○○時間短縮できたと報告すればいいのではないでしょうか？
Twitter、APIを有料化へ 無料提供は9日で終了 「詳細は来週発表する」 - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2302/02/news171.html
「Twitter API有料化」の影響範囲は？ 現状から予想できること（1/2 ページ） - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2302/02/news204.html
Twitter、APIを有料化へ - CNET Japan
https://japan.cnet.com/article/35199526/
イーロン マスク氏は、これまでも社員のリストラや、サードパーティの
クライアントアプリの遮断など、強権的な新施策をつぎつぎと打ち出しています。
Twitter、約4400人の契約社員「通知なく」リストラか。正社員に続いて | Gadget Gate
https://gadget.phileweb.com/post-21187/
Twitter、サードパーティアプリを全面禁止。無言で新ルール追加 | テクノエッジ TechnoEdge
https://www.techno-edge.net/article/2023/01/20/735.html
これらの施策に対して、世の中では、否定的な見方と、仕方ないという見方と
むしろ肯定的な見方と、自分は関係ないという見方に分かれているようです。
「詳細は来週発表する」なので、APIを利用した検索、投稿、ID連携など
どの部分に影響するかはわかりません。
しかし、サードパーティアプリを全面禁止している理由が、広告非表示だった
ので、APIを利用した検索は、有料化の可能性が高いと思います。
私の場合、APIを利用した検索で検索した結果をGoogle Apps Scriptで
ブログの数は６つ、それぞれ1日1回の検索なので合計1日6回の検索をして
いました。
ツイッター以外にもYoutube,koboなども検索してあわせて自動投稿していますが、
ニッチなテーマを検索していたので、1回あたりのツイッター検索の最大件数
100件くらいがちょうど良く、個人的な情報収集に役立っていました。
また、自動投稿していた、ブログは当然公開されていたので、ごく一部の
ニッチな分野の調べものをする人には、多少の役には立っていたと思います。
しかし、これらのブログは収益は無いので、API有料化により、終了となります。
ツイッターAPIの知識が、全くなかった私が、やっと作った自動投稿処理も
もう使えなくなります。
世の中には、同じような人が、いるんじゃないかと思いましたが
そうでもありません。
有料化したら、継続は困難なので、自動投稿処理の停止(トリガ―削除）の
やってくれてありがとう。
でも質問が悪かった。あやまる。
正確に言うとGoogle Apps Scriptなんだ。
GASでは無理だけどjavascriptではできるのか。
大企業ではほとんど採用されていると思うが、メールゲートウェイ型のセキュリティアプライアンスで、添付ファイルが
ついていたら暗号化解除して中に含まれるファイルに悪意があるマクロ、プログラムが含まれるものがないか検査して
OKだったら送信許可、NGなら削除されましたの通知だけを送るなどをしている。
従いスキャンできないと、一律でメールは削除、若しくは添付ファイルは削除されましたの通知のみ送られる。
企業のセキュリティポリシーとしてこうしているところはあります。ウイルス感染対策の検知対策確度を上げるため。
さらに、ローカルPCにウイルススキャンが入っていて添付ファイルをローカル保存するとき、開くときにスキャンが
メールゲートウェイ型アプライアンスで、企業のインバウンド/アウトバウンドメールを一律、
チェックしたいんじゃないのかな。それなりに意味はあると思いますが、例えばgmailだと、
これまで暗号化解除(解析&解除)でチェックしていたと思われるが、CPUリソース食いまくりな事
や実効性への疑問(ほかの対策若しくは、複数対策を組み合わせる事での効率化)があって、
添付ファイルはチェックされず送られるか、削除されて何も通知されないみたいです。
> 3、なんで毎回同じPWじゃないの？
同じパスワードだとそれが漏れたり、第三者に知れたら容易に暗号化解除して見れてしまうから。
> これは1の通り、プロキシサーバーでスキャンできる仕組みを作る必要があるってことでいい？
プロキシーサーバではなくてメールゲートウェイ型アプライアンス(古くはオンプレでInterscanなり、、最近は知らんけど)
> この場合既存の仕組みを使えないし、クラウドサービスにロックインされるし
> 腰が重いのもわかる気がする
なにか同等のサービスがあると思う。
とりあえず、G Suite(旧google apps)だとgmailのメールフィルタ機能が標準装備でゴミメールはだいぶ減る。
メールソフトへの実装があまりはやらなかったのもあるし、暗号化強度の問題もあったのでは。(推測)
公開鍵暗号方式の実装したもので使いやすいもの、若しくは この手の送り手/受け手が正しい人かつ、
悪意を持ったプログラムが含まれないことを担保できるメール送受信の仕組みを作ればよいと思う。
インターネット自体は、自律分散系システムなので送ったものが必ず届くという確証もないし、
LotusScript
Firebase(Cloud Functions、Firestore、Storage、Hosting、PubSub)
React(ReduxやNativeは触ってない)
GCP(Cloud Functions)
ImageJ
AsciiDoc
サービスエンジニアという名の雑用やりながらしばらく独学で勉強した後、転職して社内SEという名の雑用してた
会社に出入りしてたベンダーの職場環境があまりに魅力的だったので雇って下さいと言ったら雇ってもらえて今に至る
今はあえて言うならWeb系のバックエンドという名の雑用をやってる
職場環境は確かに最高なんだけど、そろそろ地頭の悪さが露呈してクビになりそうで震えてる
400万
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
