garbagetown

個人の日記です

#WEBエンジニア勉強会01 で発表しました

WEBエンジニア勉強会 #01 (東京都, 新橋) でお話してきました！

connpass.com

発表資料はこちら。

経緯

4 月中頃に知人の濱野 (@engineer_osca) さんから勉強会を開催するので時間があれば協力してほしいと連絡頂きました。開催は 6 月とのことだったので、5 月 20 日の JJUG CCC までは動けないけど、そのあとでよければ協力するよー、登壇でも LT でもなんでもやるよー、と安請け合いしてしまいました。懲りない人ですね。

資料は CCC のリプレイでいいかなーなんて思っていたのですが、開催趣旨をよくよく聞くと特定言語やフレームワークに依らない方が望ましい、枠も 30 分とのこと。スプリングブートの 50 分ものじゃだめですね。

運良く(悪く？) OAuth 2 についていろいろ調べながら四苦八苦していて、「OAuth 2 ってむずかしい…自分ならこう説明するのになあ」という想いが溜まっていたので、それを吐き出すことにしました。

目的

なかなか抽象度の高い勉強会タイトルだったので少々悩みましたが、以下を目的に設定しました。

  1. JJUG CCC の反省を活かすこと
  2. 聴講してくださった方が OAuth 2 を学ぶ際に自分と同じ遠回りをせずに済むようになること
  3. 新しい知り合いを増やすこと

1.については後述の KPT で。2.についてはアンケートがないので詳細は不明ですが、この辺りのツイートから察するにまずまず達成できたと思っていいのかな。

3.については、イベント後の懇親会などで数名と名刺交換してお話できたので良かったです。

KPT

以下、簡単に振り返り。

  • Keep
    • CCC でまとめたマスタースライドを使い回して作業を効率化できた。今後もマイナーチェンジはあると思うけど、飽きるまでは継続
    • CCC よりもまとめをしっかり書いたら締まりが良くなった。継続
    • 付録に参考資料を多数掲載したところ好評だった。継続
  • Problem
  • Try
    • 聴講者からもっと質問を引き出してみたい。Slido を使ってみる？

Ask the Speaker

以下、登壇後やアンケートなどで頂いたご意見に対する回答。って言っても 1 件のみですが。

悪意あるクライアントにアクセストークンを渡してしまったらどうなるの？

当然、認可された範囲内でリソースオーナーの意図しない操作を実行される可能性があります。トークンは合鍵のようなものなので、信頼できないクライアントに預けてはなりません。

とは言え、下記のとおり ID/パスワード を預けるよりは遥かに安全ですね。

  • くり返しだけど、クライアントは認可された範囲内の操作しか実行できない
    • ID/パスワードを預けた場合、クライアントはやりたい放題
    • クライアントにパスワードを変更された場合、リソースオーナーはどうすることもできない
  • 認可サーバに連絡して当該クライアントに発行したアクセストークンを無効化できる
    • Twitter で言えば、アプリ連携を解除する
    • リソースオーナーが特定のクライアントのトークンを無効化する仕様は RFC 化されていない (と思う)
    • クライアントが特定のリソースオーナーのトークンを無効化する仕様は RFC 7009 で定められている
  • (認可サーバがアクセストークンのリフレッシュを自動処理しない場合) トークンの有効期限が切れれば使えなくなる

トークンのリフレッシュや無効化は時間の関係上、説明できなかったので、とても良い質問だなと思いました。

感想

今回の感想はこれに尽きます。

なんとなく分かった気になってスライドを書いて、RFC を読み返して間違いに気付いてスライドを直して、のくり返しでした。

発表の機会がなかったらここまでしつこく RFC を読み直さなかったと思います。貴重な機会をくださった濱野さん、ありがとうございました！

あとは、これですね…

16GB MacBook Pro と IntelliJ IDEA Ultimate をご用意頂ける企業様からのお声掛けをお待ちしております…