よいしょー

のりさんかいちさんという向上心のある素晴らしいメンターがいるのがとても羨ましく思いますさて本題なのですが知っていたら教えてほしいことがありますOOS 2.0とはメリットは安全恥ずかしながらいまだにセキュリティの仕組みがよくわかっておらずフレームワークやライブラリーにお任せしてしまってます例ララベルだったらオーセンティケーションレールズだったらデバイスファイアベースオースなど

他にもOpenID Connect、SAMLなどもあり、一見難しそうに見えるので理解を後回しにしてしまっています。でも個人情報漏洩とか怖いので理解しなきゃいけないと思っています。ぜひご教示お願いできないでしょうか。

ということでお便りありがとうございます今回はお便り会でございますやったぜ一番幸せなんですよねお便り会がいいですねやっててこういうのをやって我々も成長しつつって感じですねそうですねちゃんと理解してないと喋れないですからねそうですねほぼほぼわからなかったです何を言ってるかすらわからないわからないです何を言ってるかわからないそういう人もいますよねそりゃそうだよねまずツッコミとかいろいろあると思うんですけどえーと

ラジオネームセットエンフォースゼロってこれはどういう意味ですかこれはですねSE Linuxの保護モードみたいなやつをおそらくフォルスにしてると思うんで無効化してますねこの人は今非常にオープンなマインド状態ですっていうことを表してるとそうですなるほどねあれです武器持ってないよみたいなそういうことですね両手もハンズアップしてるハンズアップしてる感じ分かんないけど

結婚式で言うとお父さんが手袋持ってる状態ですねそうそうそうか分かんない今日武器じゃなくて手袋を持ってるんで戦いませんっていう意思表示ですそうなのホテルマンが右手を拳握って左手で上から包み隠すようにすることによって殴りませんよってアピールしてるのと同じってことですかあれもセットエンフォースゼロですね東大のマークのペン武器に対してペンが上にかかってバツンと出るじゃないですか

これはちょっと違うってことですよね知らない知らない東大の交渉はそうなんだね違う?全然知らない急に畳みかける雑談雑学か海生高校だったかもしれない次いきましょうかなるほどねちょっと高度なラジオゲームですごいなんか怖いんですけどもしかしたらこれ全部知ってる知ってる食べされてる本当だよね

知ってて試されてる可能性あるなこいつらのレベルを測ってやろうじゃないなので一旦じゃあ僕のざっくりした理解からいいですか僕この辺めっちゃにわかぜなんですよ大丈夫ですか最初からちゃんと説明しなくていいですか僕ちゃんと説明する気満々ですよマジで?でもちょっと俺の今の曖昧な理解聞いてもらっていいですかわかりました喋りたいならオーホースはあのー

よくあるじゃないですかTwitter認証とかGoogle認証みたいな感じで他のサービス使ってログインできるよみたいなそれ系のやつあ、あってるあってるオープンIDコネクトもだいたいそれ系のやつあ、あってるあってるサムルはだいたいそれ系のやつなんだけどよくシングルサインオンってやつとセットで使われてるという雑な認識をしてますはいはいはいはい

あってますあってますあってますあってます必要十分じゃないけど必要です必要条件であってます必要不十分必要条件であってます必要不十分ですはいということで今日はちょっと僕も引き戦にいやー怖いなーちょっとちょいちょい補足いただきたいんですけどまあじゃあまずお便りですね

えーと何個か聞きたいことがあったと思って3つですかね まずオース2.0って何ぞやって話とあとはですねライブラリのフレームワークにお任せしたってて他のオープン id コネクトサムルーとかとのちょっとなんか違いとかようはありませんと いうのでお悩みかと思うんですが今日は

オース2.0ってだいたいこれだよねっていうのが分かるっていうのとあと並べて語られるオープンIDコネクトサムルあたりと何が違うんだみたいなところを分かるように説明しますラッキー分かるように説明します違かったら本当にすいませんって感じなんですがそういうこともあるよですねまず順平に対してですね

ララベルのオーセンティケーションレイルズのデバイスみたいな話って何の話してるか分かりますか全く分かりませんですよね全く分かりませんこの辺のお話からさせていただくんですがまずこれってララベルレイルズフレームワークですとそれぞれPHP Rubyのねそれらのフレームワークを使ってアプリを作るときって研修とかでもやったと思うんですけどユーザー管理するじゃないですかはい

その辺の実装ってちょっと大変じゃないですかだった気がしますパスワードとかパスワードもDBに生データで保存したらダメとかハッシュ取ってみたいなめんどくさって感じじゃないですかこれをメソッドでポンってやってくれるのがオーセンティケーションとかデバイスですオーセンティケーションっていうライブラリーきっとJavaにもそれのやつあるとストリングに入ってる気がする

なるほどなるほどって感じですねなのでOOS2.0やりてえと思ったらこの中の何かのメソッドを使って実装するような形になっていると思いますそれでいうとラベルはOOSはOOS用のパッケージありますねそうなんですねソーシャライトとかパスポートとかそれ系だった気がするいずれにせよそういうライブラリーですはいはい

でそのライブラリがやろうとしているのがOOS2.0とかOpenID Connectとかサムルとかの話になってきますとはい次OOS2.0です次OOS2.0OOS2.0の話はいこれ非常に分かりづらそうな名前をしてますなんとなく認証っぽい名前してますけどなので分かりやすく

オース2.0をビュッフェと例えるビュッフェまたしてもですねっていう話をしたんですが大動けしましてしましたねあの

この3人でどうやったらビュッフェに例えられるかっていう議論を1時間して1時間した結果特殊ビュッフェが誕生しました戻ってこれましたねという感じなのでじゅんぺいがすごい真っさらな気持ちで聞けなくなってるかもしれないんですけど真っさらな気持ちで聞いてくださいそこはもう演技派男優なのか意味わかんないとこは言ってください俳優って言えなんだよはいじゃあビュッフェで例えていきますはいシチュエーションは

ビュッフェなんですが羊を連れているお客さんお坊ちゃまとですねお坊ちゃまお坊ちゃま金持ち男女おじさんかもしれないですけどがビュッフェに来ているシチュエーションですねでそのビュッフェもやや格式高い感じですね

注文するタイプですか?取りに行くんですけど本当に本人確認が厳しいです毎回必要?いや、毎回じゃないです最初に必要です入るとき必要でお金持ちの人はとある事情によって自分でビフが取りに行けない有名人だろうかな有名人かもしれないっていう状況を思い浮かべてくださいちなみにこれはどれをどれに当てはめていけばいいですか?えー

まず本当の話をするとエンドユーザー自分とその使ってるアプリ今回でいうとスラックとスラックの奥で何かを認証するのを想像しましょうかGitとかにします?スラックの奥って何使うんだろう普段あれじゃないですか普通にユーザーがいて

ユーザーがアプリケーションを使ってますとそのアプリケーションの認証のところでスラックを使ってますみたいな感じがいいんじゃないじゃあそれを想像しましょうか今回でいうとそのユーザーはお金持ちおじさんですユーザーが使っているアプリ真ん中にいるやつが執事ですスラックがホテル側はい

料理の達人達人というか料理渡すマン料理サーバーですね料理サーバーですね3人いるんですね大きく2ステップがあってまず本人確認フェーズ本人確認フェーズがあってからの料理取ってきていいよフェーズがありますお高いところですかお高いところなるほどね予約制ってことですか予約制なんではい

でオース2.0のビュッフェ版のお話をしていくんですがこれからはいファーストステップファーストステップ来店来店いらっしゃいませいらっしゃいませまず本人確認をしますはい予約の何々さんですねとはい確かに顔も合ってるしIDもパスワードも合ってるし本人やねと

どうぞどうぞお席についてくださいこれ本人確認フェース執事と一緒に入ってるんですよねそうですね認証次この料理食べていいよフェーズなんですがまず認可リクエストっていうのを出すんですがどういうことかっていうと今日この料理食べたいんだけどいいかねとメニューも予約してあった

ビュッフェなんでコースなんでなんでしょうねひいきにしてる石焼きビビンマンみたいなのがすいませんよくわかんないなんか料理があって今日この料理食べれるかねと中華系の料理食べたいんだけどビュッフェには並んでるかねっていうのをホテル側に出しますこれは羊を通さず直接言いますホテルの人料理提供してくれてる人に注文か何か

でホテル側から羊にいいよってあるよ料理料理あるよっていうOKコードが返ってきます羊に返ってくるその後この人はこのお客さんはもう有名すぎて大騒ぎになるんで自分で料理取りに行けませんと羊が代わりに行くっすとなので羊が取りに行ける件欲しいんだよねと

いうので羊がすいません僕取りに行きたいんですけど僕取りに行っていい件くれませんかというのをホテル側にお願いしますなるほどねちゃんと目印持ってないと料理取れないよってことですね取れませんホテル側から羊にこれ取っていいよ件が返ってきますこのバッジつけてたら貴様は料理取っていいぞとこれいわゆる大オースでいうとアクセストークってやつですねうんうん

このアクセストークンを執事が受け取った時点でこの料理取ってきていいよフェーズ認可フェーズはOKになります執事がバッジを獲得したら加入と加入完了そしたら執事は料理を取ってくるっていう安全料理を取ってくるということができますこれ何が嬉しいかっていうと執事が料理取ってくれるのが嬉しいんですよね

自分で行くわけじゃなくて第3サードパーティーアプリってやつですよね第3社のアプリの情報を引っ張ってきて例えばさっき言ってたのりさんの例の間のアプリケーションで奥にスラックがいる場合スラックにある投稿とかを引っ張ってこれるんですかねスラックにある機能をいろいろ使えるとそれをやりやすくしたのがOS2.0っていう認証方法にはなるんですが

要はこれ簡単に言うとAPIがあってそれを安全に使うための仕組みってことですか作用APIがあって1個かませて安全に使うための仕組みですAPIってそういうもんじゃない?フロントエンドそうですね合ってます確かに確かにそうですね

適当な認証じゃなくてちゃんとこういう手続き踏んだら安全にできますよっていう手続きがさっきのなんか羊が云々かんのやつそうですねあと一個重要なのが自分の全部味方の味方というか身内のフロントエンドとバックエンドじゃなくて関係ないやつのバックエンドを安全に叩けるっていうのが多分ポイントなんだと思いますなるほどね要はもうお坊ちゃまと羊ペアがいろいろたくさんいても

全部安全にやり取りできるとそうですそうですRFC6749のアブストラクトにはサードパーティーHTTPサービスへの制限付きアクセスを取得するための仕組みですってことが書いてあるのでポイントはサードパーティーサービスへの制限付きアクセスっていうところがポイントだと思いますあれですかその

いっぱいその羊とお坊ちゃんのペアがいっぱいいていっぱいいる厨房にその羊がわーって殺到しちゃってもうんそいつらはちゃんと喧嘩せずにうんちゃんと料理を自分のお坊ちゃんのところへみんなちゃんと届けられるあーそうそうそうえそう?え?

むしろあれじゃない?たぶん、執事と、その執事がいっぱいその厨房に行くんだけど、そこに順平が紛れててもちゃんと弾けるってことなんじゃない?それもそうですし、あと執事A、執事Bがいて、執事Bが執事Aの範囲の料理って言うんですかね。執事Aは中華料理しか頼めない人、執事Bはフランス料理しか頼めない人だとして、フランス料理しか食べられない人が執事Aの

フランス料理が食べれない人が中華料理を注文してもお前権限ないやないかいってちゃんと言えるコースがいっぱいいろいろあって別のコースに頼めないようにうまくなってるってことですかなってるってことお坊ちゃん自体もいけないとお坊ちゃん自体はいけるんですけど多分トークンは持ってるんで

行かなくていいって席ついててっていう座ってて大丈夫行かなくていい安全なやつなんですねへーなるほどちょっとあの例えが複雑すぎて意味わからんくなってるかもしれないんですけどそうだね絵が欲しいですから一旦普通に普通のフローを説明しておくすいませんがじゃあ普通のフローいきますねはい

今更で申し訳ないんですが認証と認可って言葉が似てると思うんですがここの違いは確かに説明した方がいいかもねちょっと説明しましょうかお願いします逆になんですけど逆にですね説明してほしいなではですね認証と認可についてまず認証は使う人と認証する人がいて使いたいですって言ってOKだよっていう

認める認めましたっていう証としましょうはいはいはい認可は認めてもいいかなっていう考えを持った人人?そういう思想の人たち心広いんだねどうでしょう

まあなんか認証はギリギリ60点って感じだった気がするけど認可は0点でしょ勝手に分かんない教えてくださいざっくり言うと認証は本当にビュッフェのまんまで本人確認あなたがうちの名簿に入ってる人のうちの一人ですねっていうのを確かめるというかOKそうやなっていうのが認証認証だけじゃなんもできなくて認可っていうのはえーと

何々ができるよねっていうのを認めてあげる行為権限だね権限与えてあげる行為あなたは部下だからここまでしかできませんあなたはマネージャーだからここまでできますよっていう振り分けみたいな感じだよねなるほど運転するためにできるよねっていうので

腕2本足4本ついてるよねっていうのがあってそれくれづらいわ思ったのと全然違ったわ俺あれで来るのかと思った普通用の乗用車の免許持ってたらここまで運転できるよね大型持ってたらここまでできるよねって範囲違うっていうので来るのかと思ってそれで行きましょうなんかおかしな変な感じになっちゃいましたね

乗用車の免許だったらそこまでできて大型持ってたら別に普通免許の車も運転できるし大型車も運転できますよねとそれだと認証の部分は認証はあなた誰ですかってやつですね例えばじゅんぺいとのりの免許証ありますよと本人確認するのが認証ですよとお兄さんお兄さんちょっと待って

あの今検問やってるから免許証見せてっていう状況ですよね多分そうはいじゃあ免許証見せてって言って顔見てあー本人っぽいわだって変な顔すんだよちょっとすいませんで認証ですねで認証した上であー普通車免許だ普通車だじゃああなた普通車運転できる権限持っとるわが認可そう

本人確認&権限チェック本人確認&権限チェックはいこれは認証と認可なんですがでオーオースオーセンティケーションらしいんですけどそうなの?RFCに何も書いてなかったのでそのままオーオースなのかなと思ってましたちなみにRFCというのはリクエストフォーコメント

世の中のプロトコルとかいろいろな取り決めを定義している原初みたいな思想工事園みたいな仕様書みたいなグローバルスタンダードな仕様書みたいなHTTPとか書いてますそこにそこ読んだときは間違いない一時情報

まずAuth 2.0ファーストステップ認証をしますと認証は間にいるアプリケーション経由で奥にいるスラックリソースサーバーに認証を飛ばします認証してーって俺スラック使ってるこういうもんだけど認証してーって送りますで帰ってきますと

認証結果がどこにいるんですか自分のところにローカル端末これはもちろんアプリケーション通ってますけどね認証したら次に認可をしようとします認可は次自分エンドユーザーというか自分から奥のスラックにここのリソース触りたいんだけど許可してあげてくれないうちのアプリがここ触りたいって言ってるんだけど許可してくれないっていう認可を飛ばします認可リクエストを飛ばします

認可ってこれユーザーに許可取ってるんじゃない?いいよって言ってるってことですねユーザーに許可取って今回この権限でアクセスしようとしてきてるけど大丈夫?って聞き返してるみたいな感じその通りでございます最初の認証が終わった時にここでこのリソースにアクセスしようとしてますがいいですか?

プロフィールメッセージみたいなそれはあれだよね要はスラックと間にあるアプリとユーザーがいてスラックからユーザーに来るやつだよねでいいよってユーザーが言っていいよって言われたらリソースサーバーはよっしゃいいよって言われたから言われた範囲なら何やってもいいわってなってスラックはアプリケーションにじゃあこの認可コード

使ってトークン取得してねって言います待ちに待った最後のステップ認可コードをもらったアプリケーションはトークンが発行できてそのトークンで何でもできるAPIにアクセスすることができるようになるので認可コードを使ってアクセストークンのリクエストを出しますスラックに認可コードはリソースサーバー側がユーザーが認可したよっていう証拠になるだけでまだアクセスはこれだけじゃできないってことですねそうですね

でトークンを要求したら最後トークンが返ってきてアプリケーションはこれでトークンを持っていますそのトークンを使ってAPIを呼び出して奥にいるリソースサーバースラックの情報を引き出していろんな表示ができます通のがOOS2.0これであればユーザーの同意も取れてるし認証も認可も済んでるから安全にやり取りできるよねっていうのがメリットってことですかねそうですねなので

OOS2.0とはっていうところはちょっと音声で複雑になっちゃったかもしれないですけど仕組みはこんな感じでさっきのフローのことをOOS2.0と言いますかねそうですねで安全ですとちなみにちょっと調べた感じだとやり取り自体は安全なんだけど間に挟まっているアプリケーションに悪意があると

結局スラックの情報とかを悪用できちゃうから今使ってるアプリが安全かどうかのチェックは必要って感じらしいですねそうですねユーザー目線だとそうですね実装者目線だとでも安全にやり取りできるよって今言われてるとなのでメリットとしては裏側にいるサードパーティーの多分Googleとかスラックとかの情報を取ってくるときって適当に取ってこれないと思うんですけど

安全にとってこれこれ実装する側になる人ってさ相当レアじゃない僕は経験ないけどまあでも大オースの連携して認証できますよっていうのを提供する側になるとだよねLINEとかスラックとかGoogleとか結構でかいサービスの人じゃないと触る機会なくないその手前のアプリケーションはあるんじゃないですか

そっちはでもあれじゃんドキュメントに沿ってリクエスト送ったりするだけだからそんなに難しくなくないそれはそうだと思います危険じゃないしそれはそうだと思いますでしあと普通にデバイスにも入ってますしレールズのだからこの仕組みを本当にちゃんと理解して実装しなきゃいけない人っていうのは多分めっちゃ有名なサービスのすごい大事な部分触る人だから結構レアな気がするとかOSS触ってる人とかうん

本当にこういう風になってるんだ程度で僕もいいと思います使う分には全然理解してなくても本当にビュッペの話だけでいいと思いますっていう感じですねちょっと補足的なところでオープンIDコネクトサムルーみたいなのがあるっていうのをお便りに書いてましたけど

正直ちょっとふわっとした理解で恐縮なんですがAuth2とAuth2.0とOpenID Connectが似ててサムルは別のもんだと思ってくださいはいOpenID ConnectはAuthと違って認可の範囲が違いますどういうことかというとAuth2.0はここのパスにアクセスしていい?っていう認可リクエストを飛ばすんですけどOpenID Connectは

全体的に叩いていいっていう認可のリクエストを出しますなのでオープンIDコネクトの方が汎用的というか権限の範囲が広い広いようなイメージをしておけばいいと思っておりますIDトークンそのぐらいの程度にしておきましょうか

オープンIDコネクトはなのでオース2.0をベースにした仕組みですなのでオース2.0とオープンIDコネクトは並べられるものっていうよりはオース2.0をちょっと広げたのがオープンIDコネクトはいなんで系譜一緒なるほどね

今ってでもOpenID Connectの方が主流なのかな僕は今OpenID Connect使ってますこの僕もスラックの認証機能を使うアプリ作ったんですけどその時はOpenID Connectになってましたねですよねこっちの方が主流みたいですね実際

サムルまた別物でやりたいことは似てるんですよオープンIDコネクトもサムルもシングルサインオンに割と使う仕組みなんですけどサムルはさっき言ってたオープンIDコネクトと違って大きく2つ違いがあって1つ

こちらは小さいんですけど渡されるやり取りする情報の形式が違いますオープンIDコネクトはJSONを使うんですけどサムルはXMLという形式でありますこれは大した違いじゃないです実装上違うんですけどね2個目こっちが大きく違ってサムルはオープンIDコネクトとかオースと違って

この情報を使うけどいい?っていうユーザーに対する認可要求がないんですよつまり勝手に裏側で色々連携してくれるのがサムルなので実装者目線で言うと何でもかんでもサムルにするのってまずくてはい

基本的にはユーザーに合意を取りつつ情報を連携するのが基本なのでオープンなアプリを作るときにはオープンIDコネクトを使う方が望ましくてじゃあサムルどういうときに使うかっていうと社内アプリ社内のいろんなシステムがあると思うんですけど決済システムとか会計システムとか物品調達システムとかいろいろある中の情報を全部連携させるのっていちいちユーザーに同意を求める必要がないでしょうっていう思想のもと

勝手に裏側で色々連携してくれる仕組みとしてサムルがあるみたいですなるほどちなみにサムルってファイルではないんですかプロトコルなのこれって名前めっちゃファイルっぽいですよねマークアップランゲージだしねGoogleとかでシングルサインオン実装するときって多分.サムルみたいなファイルを管理画面にアップロードしたら

さっき言ったような社内アプリとかでそこに共通のサムルみたいなやつ出すんですよそれをGoogleの管理画面にアップロードするとシングルサインオンで1個の認証で全部で使えるようになるみたいなこと確かできるんですけどサムル認証っていうワードだけ見てたんですけどサムル認証っていう企画かXMLをベースにした標準企画ですって

パッとググると出るので多分そうなんだとなるほどねそのサムルを使っている認証がサムル認証でよくシングルサイン用に使われるよってことかそうですね軽く触れるとそんな感じらしいですえーと

これは1年後ぐらいにちょっとリメイクしたいあーわかるーちょっとね散らかっちゃったーちょっとねー申し訳ないもう少しオースに対して詳しくなってからもう一回喋りたい気持ちはあるねこれ詳しいのが問題じゃなくてなんか説明力の問題な気がするわあマジで?うんオースに詳しくなるのって多分

なりたい?なんて言うんでしょうそんなモチベーションないんですよ俺もねモチベーションで言うとないわなんて言うんでしょうその大枠は理解しててフロアも理解しててどういう時に使うかも理解してれば良くない?っていう範囲のものだと思うのでそうだねどっちかっていうと使えれば大丈夫かなって気がするそうですねっていうのでただもうちょっと分かりやすくできたら本当にすいません散らかっちゃったうまく編集の力でどうにかしましょう片付けましょう

若干アフタートークなんですけどこのお便りで特にじゅんぺいさんの考え方や感覚が自身がエンジニアとして働き始めた頃を思い出したびたび共感しておりますっていう文言があるんですけどこれめっちゃ思ってる俺もじゅんぺいの関数命名の漢字とか確かにいやわかると思って恥ずかしいすごいね

いいんだよそれがチェックなんとかみたいな恥ずかしいすごいねわかるわ

って思うので本当に大切にしていかなきゃいけない部分ではあるんだけど大切にしちゃいけないんだよねこのひまじんプログラマーのジレンマと名付けたいんですけどじゅんぺいの成長するラジオなんですけどじゅんぺいが成長すると面白くなくなっちゃうっていうジレンマですねこれは探っていきたいちょうどいいとこちょうどいいとこ成長しつつちょうどいいとこ見せていきたいですね

定期的にね順平が成長してきちゃったら頭一回ぶん殴ってアップデートかけないといけない2ヶ月分くらいの記憶を飛ばすみたいなやめてくれしばらく嘘だけ言う機会がいけないかもしれないバカを演じる実はここ1年間全部嘘を言ってた本当にお便りありがたいですねありがとうございます

こういうのをきっかけに僕らも学び直したね普通に確かに成長していきましょう聞く機会もないですから僕なんて大オースとか初めて聞きましたけどそうなんだ聞くもんなんですかねこれは大オースとかは結構意識してないから入ってきてないやつなのかなそれはあるかもしれないけど現場で聞くかって言ったら俺はあんまり聞かないんだけど普通に自分でいじっててパソコン触ってて見るなってニュースかな

ニュースかも何で触れたかって言ったらニュースか資格勉強かどっちかだわちょっと忘れちゃったけど結構なんかスラック認証とかLINE認証とかでアプリ作るから作るんですね割とそれで見るかなでも勉強になりましたこういうのも勉強でいいですね多分このポッドキャスト聞いてる人もそういう人いると思うので

本当ねマジで例えひねり出すところで議論しすぎてめっちゃフロー分かったもんですよね今日逆にじゃあなんかこの仕組み理解したいと思ったら例えて説明しようとすると理解できるってことが今日分かりましたね確かに

はいなのでちょっと皆さんも今日から分からないことあったら全部ビュッフェでたとえていきましょう絶対やめたほうがいいよチラしたほうがいいビュッフェでたとえていきましょうそれではOS 2.0勉強してということでセキュリティもできるエンジニアになっていきましょうはいセキュリティそれではまた次回バイバイ

イマジンプラグラマーではメールを募集していますトークテーマ悩み要望などなど何でも募集中です宛先はhima pro 11 at mark gmail.comhimapro 11 at mark gmail.comになりますそれではまた次回