『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』を読んだ

目的

前作に続いて、OAuthとOpenID Connectの違いを理解したくてこの本を読みました。

techbookfest.org

感想

こちらも前作に続き分かりやすく解説されていて、かつサクッと読めます!

タイトルにもあるように、OAuth、OAuth認証、OpenID Connectの違いが整理して書かれているため、OAuthと比べてどこがどう違うのか上手く説明してくれています。

第2章でOAuthの復習の章を設けられていますが、個人的には前作の『雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本』を理解した後にすぐ読んだほうがより理解がしやすいのかなと思います。

techbookfest.org

あと、個人的にコラムは絶対読み飛ばさないほうが良いです!

OAuthの脆弱性やアプリのログインに脆弱性があった場合にどうやって攻撃されるのかが説明されているので、読み物としても面白いですし、実際にこうやって攻撃されるのかとOAuth認証やOIDCへの理解も深まると思うので。

読書ノート

  • OAuth認証
    • アプリはプロフィールAPIで得たユーザー識別子の情報などを利用して、ユーザーの認証が可能になる
    • OAuth認証、アプリのログイン実装の脆弱性についてのコラムが面白い - p29
    • Facebookではなりすましログインへの対策に /debug_tokenエンドポイントという独自エンドポイントを用意している
  • OpenID Connect(OIDC)
    • OAuthに IDトークン・UserInfoエンドポイントを加えたものを言う
    • IDトークンはユーザーの認証に利用
    • UserInfoエンドポイントはユーザーのプロフィール情報を得るために利用
    • OAuthとOIDCのロール関連用語に違いがある - p36
  • OIDCのフローは3つ
    • 認可コードフロー
    • インプリシットフロー
    • ハイブリッドフロー
      • インプリシットフローと認可コードフローのハイブリッドなフロー
      • パブリッククライアントとコンフィデンシャルクライアントの両方で構成されているクライアントに利用する
        • JavaScriptアプリ・ネイティブアプリ + バックエンドサーバー
  • OIDCでは scopeの値は仕様で決まっている
  • OAuthとOIDCの一番のち外はフローにおいて、IDトークンの発行が行われること
  • デタッチ署名とは、署名の対象と署名が分離した形式の署名のこと

『雰囲気でOAuth2.0 を使っているエンジニアが OAuth2.0を整理して、手を動かしながら学べる本』を読んだ

目的

OAuth2.0への理解を整理したい思い読みました。

techbookfest.org

感想

タイトルにもあるように雰囲気でOAuth2.0を使っている人やとりあえずOAuth2.0って何?って人にすごくおすすめです!

分かりやすいし、安い!

1~5章は、OAuth2.0とは何か?から始まり、OAuthの各グラントタイプごとにクライアントがどのような流れでトークンを受け取るか分かりやすく説明されています。

本自体は100ページ程度ですが、OAuth2.0の説明自体は60ページほどで1時間弱あればゆっくり読んでも読み終わるので、すごく良くまとまっているなと思いました!

個人的に、パブリッククライアント向けのグラントタイプとして推奨されている、「認可コードグラント+ PKCE」は知らなかったので勉強になりました!

6章は、実際にGoogleのPhoto Library APIを用いてOAuth2.0を手を動かしながら学べます。

1~5章で学んだ内容を実際に手を動かして復習できるので、理解も深まりやすいです。

OAuth2.0の説明を読んでよく分からなければ、まず6章の内容に従い手を動かしてから読むと良いかも知れません。

読書メモ

  • 認可エンドポイントとトークンエンドポイントは、認可サーバが提供するURI
  • リダイレクトエンドポイントはクライアントが提供するURI
  • トークンエンドポイントではBasic認証によって、クライアントのアイデンティティが確認される
  • Basic認証としてAuthorization ヘッダーに設定されるのは、クライアントID と クライアントシークレット
    • これらは認可サーバーにクライアントを事前登録する際に発行される
  • OAuthのグラントタイプ
    • 認可コードグラント
    • インプリシットグラント
      • 非推奨
    • クライアントクレデンシャルグラント
    • リソースオーナーパスワードクレデンシャルグラント
  • リソースオーナーパスワードクレデンシャルグラントを利用できるのは、リソースサーバーおよび認可サーバーとクライアントの提供元が同じ組織である場合
    • クライアントタイプがコンフィデンシャル、パブリックの両方で利用可
  • PKCE は「Proof Key for Code Exchange」の略で「ピクシー」と読む

2021年4月12日 ~ 18日 振り返り

先週の振り返りです。

仕事

Play2.6 Migration

先々週から引き続きPlay 2.6 Migration作業を行っていました。

ほぼほぼMigration Guideの項目は対応し終わっていましたが、以下の対応を行っていました。

  • deprecatedになったメソッドの修正
  • warningが出ているコードの修正
  • Unitテストの修正
  • 各プロジェクトのビルド・テストがCI上でALL Greenになるように修正

ほぼ一人で作業(ときどき同僚に相談乗ってもらった)だったので、なかなか根気のいる作業でしたが、無事完了できました!

あとは、検証環境で動作確認・数週間運用後に本番リリースを行う予定です。

AWS Lambda ランタイムのアップデート作業

会社の部内のプロジェクトでいくつかで使われているサービスがあり、それをだいぶ前に保守作業を移譲されて自分が担当しています。

今回、AWS Lambdaのnode.js10.xが2021年7月30日から「サポート終了フェーズ 1 」が開始されるとのことで、対応しておいたほうが良いということで着手しました。

(あれ、自分が読んだときは2021年5月末までだったけど変更された?)

docs.aws.amazon.com

Lambdaのランタイムのアップデート自体は結構すぐ対応できたのですが、ランタイムとは関係ない部分で一部エラーが発生しているのに気が付き、修正作業を行いました。

結構前に書かれたコードなのでライブラリのバージョンも上げたり、もっというとコード自体を書き直したりしたいところですが、機能が追加されたりするサービスではなく基本的に安定して稼働しているサービスなので着手できていないのが現状です。

ここらへんも保守・運用しやすいように細かいアップデートをしていきたいところです。

プライベート

ブロクにも書きましたが、4/16 (金) にAWS DevOps Engineer - Professionalに合格できました!

blog.ryskit.com

これであとはSpecialtyの資格をどんどん取っていくだけですが、ひとまずAWS以外のことも学びたいので資格勉強はGW明けまでお休みです。

今月の自分の課題図書にした「Akka実践バイブル」をあまり読み進められてなかったのでここらへんでスピード上げて読み進めていきます。

読書

AWS DevOps Engineer - Professionalに合格した

2021年4月16日(金)にAWS DevOps Engineer - Professional(DOP)の試験に合格しました!

f:id:ryskit:20210416223019p:plain

学習期間

学習期間は2週間で、1週間は試験範囲に出るAWSサービスのドキュメント等を読みさらっと流して、最後の1週間で模擬試験など受けて集中的に学習しました。

学習内容

まずはDOPの試験ガイドを読んで、出題範囲のAWSサービスのドキュメントを読みました。

AWS公式 DevOps Engineerの試験ガイド

ドキュメントにある程度目を通したら、Udemyで販売されているTutorials Dojoの模擬テストを一通り受けました。

www.udemy.com

模擬テストを受けるとだいたいの出題されるAWSサービスの範囲が分かるのと、解説を読めばこのAWSサービスで何を解決できるのか、詳細を把握できるかと思います。

模擬試験1回目は理解が深まってない状態で受けるのでスコアは悪かったんですが、そこは気にせず2、3回同じ模擬試験を受けて自分はどこを間違ったのかを把握したのが良かったのかなと思います。

間違った問題は正解の解説だけでなく、間違った選択肢の解説もちゃんと読んでおくと、自分のAWSサービスへの理解と実際のAWSサービスの挙動のズレを正せると思います。

また、解説にはAWSサービスのドキュメントリンクがだいたい記載されているので、それらはすべて隅々まで目を通すのが良いと思います。

余談

以前にAWS Security - Specialtyの試験を受験したときに勉強したAWSサービスががDOPの出題範囲と少し被っていたのがすごくラッキーでした。

領域別に試験があるとはいえ、重要なAWSサービスはいろんな試験に出題されるため、何回もドキュメントを読むことになるので理解が深まりやすいのが良いところです。

試験当日

試験日はいつもどおり7:30に起きて早めに試験会場の近くのスタバでコーヒーでも飲みながら、自分でまとめたAWSサービスの要点などを復習します。

試験前なので、水分を取りすぎてトイレに行きたくならないように気をつけました。笑

基本的にProfessionalの試験の問題文は長いし、日本語がかなり読みづらいので試験時間ギリギリまで使いました。

ちょっと不安だなと思った問題に対しては見直しフラグを立てて問題を解き進めて最後に見直すのが良いと思います。

1問1問時間掛けていると最後までたどり着けない可能性があるので、そこは気をつけたいところです。

次は?

社内にはAWS資格12冠を達成している人たちがゴロゴロいるのですが、それに追いつけるように2週間~1ヶ月に1つのペースでAWS試験を受けたいと思っています。

次は、AWS Database - Specialty(DBS)を受けようかなと考えています。

まだ6冠しか取得できていないので、あと最低5回も試験を受けないといけないのは憂鬱ですが頑張っていくぞ!

www.credly.com

話は変わりますが、6月にDBS関連の書籍が発売されるみたいです。発売されるまでには自力で勉強して合格していきたいところ!!

要点整理から攻略する『AWS認定 データベース-専門知識』

それではまた!

2021年4月5日 ~ 11日 振り返り

先週の振り返り。

仕事

先々週に引き続き、Playframework 2.6のMigration作業を行いました。

Play 2.6に移行したことでdeprecatedになったメソッドがいくつもあり、テストを実行するとwarnログが出力されてXXかYYに置き換えろと怒られるので、ひたすらそれらを修正する作業です。

ただ、素直に置き換えるとテストが動かなくなったりするので、今度はテストを修正するという作業を行ったり来たりしていました。

なかなか根気のいる作業だなとは思いますが、どういう仕組みでフレームワークが動いているかを改めて勉強する良い機会にもなりますし、自分たちのアプリケーションへの知見を深める良い機会にもなります。

マルチプロジェクトで構成されていて、テストが完全には通ってないので次のスプリントでも対応が必要そうです。

プライベート

4/16 に AWS DevOps Engineer - Professional の試験が控えているので、勉強しつつ面白そうな勉強会にオンラインで参加していました。

もう少し読書したりしたいですが、今は試験勉強に集中!

2021年3月29日 ~ 4月4日 振り返り

先週の振り返り。

仕事

先週は、Play 2.6へのMigration作業を行いました。

機能開発ではなく改善タスクに多くの時間が割ける今、フレームワークのバージョンが古いものを上げていこうとチームで動いており、先々週あたりにPlay 2.4 から 2.5 に上げて問題がなかったので、2.6 にも上げてしまおうという流れです。

ただ、Play 2.5 から 2.6 へのMigrationに関して、Migration Guideを読んでもらうと分かるのですが変更点がかなり多いです。 www.playframework.com

play-jsonがライブラリとして切り出されたり、Akka Httpがサーバのデフォルトになったりと既存のコードに影響するものが多く、「コンパイルが通らないから通るように修正 → テストが通らない → 修正すると他でエラーが出る → 修正する」 みたいなサイクルをぐるぐる回していました。

今のプロジェクトに入ってから機能追加や修正をやっていましたが、Play自体にあまり詳しいわけではありません。今回2.6へのMigration作業を通してPlayFramework周りの知識を深められればなと思って作業しているので、かなり楽しく作業を進めれています。

先週だけでは終わる量ではなかったので、次のスプリントでも作業することになりそうです。

Migration作業について

アプリケーションフレームワークのMigrationは、Migration Guideがある場合はそれらをチェックシートにして作業を1つ1つ進めるのが良かったです。

というのも、変更内容が多い場合にいくつも修正作業を同時に進めてしまうと、どれがどこまで進んだのか進捗管理が難しくなってしまいます。また、修正作業の抜け漏れも発生しやすい状態になってしまうからです。

また、Migration作業を進めるに当たり作業ログも逐次書いていくと良いと思います。

作業ログがあると時間が空いてしまった場合にも思い出しやすいですし、作業を誰かに引き継ぐ場合にもここまでこういう内容で進めたと共有しやすくなるからです。

プライベート

注文していたOura Ringが届いて、最近コンディションや睡眠の数値を改善する活動にハマっています。

睡眠時の何が悪いのかを具体的な指標で示してくれるので、改善するポイントが分かりやすいのが気に入っています。

Amazonで買うと5万以上しますが公式サイトで注文すると3万弱で買えるので、もし検討されている人は公式サイトで買うことをオススメします!

ouraring.com

やったこと

  • AWS DevOps Engineer資格勉強
  • アルゴリズム実技検定公式テキスト 6.3 幅優先探索と深さ優先探索 まで

読書

入門 監視

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

先週は「入門 監視」を読みました。もっと早く読んでおけば監視の仕組みを作る際に参考になったのになと思いながら読んでました。

監視のアンチパターンやデザインパターン、良いアラートの仕組みなど、監視についてギュッと濃い内容でまとまっています。

あと、付録Cとしてsongmuさんが書かれた実践 監視SaaSも非常に勉強になりました。

3章には「良いアラートの仕組みを作る6つの方法」について書かれているのですが、その1つに「アラートにメールを使うのを止める」というのがあります。

アラートの使い道は以下の3つに集約されると書かれています。

- すぐに応答かアクションが必要なアラート
    - SMSなどに送る
- 注意が必要だがすぐにアクションは必要ないアラート
    - 社内チャットに送る
- 履歴や診断のために保存しておくアラート
    - ログファイルに送る

お客様とチームで使っているDataDogのアラートがメールとSlackに送られており、特にメールの量が多すぎるので注意力が削られている原因にもなっているので改善の余地があるなと感じました。

  • 監視アンチパターン
    • ツール依存
    • 役割としての監視
    • チェックボックス監視
    • 監視を支えにする
    • 手動設定
  • 監視デザインパターン
    • 組み合わせ可能な監視
    • ユーザ視点での監視
    • 作るのではなく買う
    • 継続的改善
  • 良いアラートの仕組み
    • アラートにメールを使うのを止める
    • 手順書を書く
    • 固定の閾値を決めることだけが方法ではない
    • アラートを削除し、チューニングしよう
    • メンテナンス期間を使おう
    • まずは自動復旧を試そう

2021年3月22日 ~ 28日 振り返り

先週の振り返りを書きます。

仕事

あるキャッシュを作成するLambdaの処理時間がほんの少しではあるが遅くなってきていました。

キャッシュのもとになる取得先のデータ件数が徐々にではあるが増えていてそれが原因です。

処理時間が遅くなって問題が顕在化しないうちに、このキャッシュを作る処理内容やアーキテクチャをどうするべきか検討するというPBIに着手しました。

PBIを着手するにあたって問題だと感じたのは、「問題がそもそも整理されていなかった」ことです。

というのも、PBIのタイトルには「Lambdaのリファクタリングの調査」というようなタイトルで、内容には「Aに変更したらどうか?」のような感じに記載されていて、そもそも問題は何か・なぜそれが問題なのか・Lambdaのリファクタリングで問題が解決するのか、といった着手するのに必要そうな情報が不足していると感じました。

PBIを作成する場合には、自分以外の人が着手することを念頭に置き、タイトルは完結で分かりやすく・内容はそのPBIの問題やなぜやるのか?ということを明確に記述した方が確実に効率が良いなと学びがありました。

問題の内容だったり、なぜやるのか?というのを書くのは時間が掛かることかもしれないですが、書くことでチーム全員が把握できるし、何度もPBI作成者に書いた内容の意図などをヒアリングすることも省けるかもしれないので、丁寧なPBI作成を心掛けたいと思います。

プライベート

以下の記事にも書きましたが、2021/3/26 (金) に「AWS Solution Architect - Professional」に合格しました!

blog.ryskit.com

正直、試験中は問題を解きつつも自信は持ててなかったので、再試験か。。。と落ち込み気味でしたが、試験を終了したら「合格」の文字が見えて思わず「っっしゃ!」と会場で声が出ちゃいました。笑

ひとまず、SAPの試験勉強は終わりましたが、今度は「AWS DevOps Engineer - Professional」取得目指して頑張ろうと思います。

あと、初めて生牡蠣食べて当たりました。笑 めちゃめちゃ苦しいので、生牡蠣食べる前は覚悟した方が良いなと思いましたw

やったこと

  • アルゴリズム実技検定 公式テキスト[エントリー~中級編]
    • 5章 基礎的なアルゴリズムまでの問題を解いてみました。

AWS Solution Architect Professionalに合格した

2021年3月26日(金)にAWS Solution Architect Professional(SAP)の試験を受験し合格しました!

次のDOPの試験に向けて自分がやったことを整理しようと思います。

学習期間

学習期間としては、1ヶ月(ダラダラ) + 1週間(超集中)というところです。

正直ダラダラ試験勉強するぐらいなら、好きなことやってた方が良いです。無駄な時間の使い方をしたなと思い反省していています。

超集中した1週間は毎日5~6時間ぐらいは勉強していました。内容については後述します。

普段は夜更し気味だったんですが、試験一週間前はさすがに生活リズムを取り戻さないといけなかったので、12:30 ~ 1:00 には眠りにつくように心がけてました。

好きだったフォートナイトも試験直前はさすがに我慢しました笑

学習内容

以下の模擬試験を分からなくても良いのでとにかく解きまくりました。

模擬試験が終わると、解説と参考情報が出てくるので、それを読みつつAWSの公式ドキュメントも隅々まで確認するというやり方をしていました。

とにかく公式ドキュメントやFAQに書いてることは問題として出されても良い状態にまで持っていくのが良かったと思います。

模擬試験をやっていると自分が不得意なAWSサービスが分かってくるので、あとは理解できてない部分をひたすらドキュメントを読んで確認します。

僕の場合はDirect ConnectやActive Directory、Route53などのサービスをあまり理解できてなかったのでよく勉強していました。

Direct Connectに関しては実際にさわる機会もあまりないのでよく分からなかったですが、佐々木拓郎さんがブログでまとめてくださっていたのでこれを読んで理解していました。非常に助かりました!

blog.takuros.net

blog.takuros.net

blog.takuros.net

blog.takuros.net

blog.takuros.net

試験当日

10時から試験開始だったので、7:30に起きて試験会場近くのスタバで勉強のときにまとめたメモを見て最終確認をしていました。

注文したのはラテのトールサイズで、朝起きてからあまり水分を飲まずに行きました。これが非常に良かった!

というのも、前回受けたAWS SCSの試験のときは、ラテのグランデサイズを注文して、試験の後半トイレ行きたいしか考えられなかったからです。笑

今回はそのようなこともなく最後まで集中力を保ちながら問題を解くことができました。

まとめ

超集中して短期間で勉強し、睡眠はたっぷり取って、試験当日は水分をあまり取らずに試験に臨む!これだけ!

次は、AWS DevOps Engineer - Professionalを頑張るぞ!

2020年3月15日~21日 振り返り

プライベート

やったこと

  • AWS Certified SAPの勉強
  • AtCoder ABC 196 参加

AWS Certified Solution Architect Professionalの試験が今週控えているので、それに向けて模擬試験を解いて解説を読んだり、ドキュメントを読んだりしていました。

あと、土曜日のAtCoderのABCコンテストに初参加しました。

思ったよりも解けなくて悔しい思いをしたのと同時に、競プロ楽しいというのは少しわかった気がします。

リアルタイムでコンテストに参加すると制限時間もあるしスコアにも影響するので、この問題は絶対ACするぞみたいな気持ちにもなりやすいので競ってる感があって楽しいですね!

読書

ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方

バグを出さない仕組みについて書かれた本。 15章まであるが、薄い本なのでサクッと読めます。

いくつかのテスト手法が紹介されているので、なんとなくでUnitTestを書いていたのであれば参考になると思います。

個人的に興味深かったのが、同じバグでも「要求や設計段階で潰す」場合と「統合テスト時のようにある程度開発が進んだ段階で潰す」場合ではそれに掛かるコストが違うという点です。

要件定義や設計段階でレビューをして、その段階で潰せそうなバグは潰しておくというのは、プロジェクトを効率的に進めるにあたって大切なんだなと感じました。

ただ、ところどころ日本企業がテストコード書かないみたいなディスりが書かれていたのは何か不快な文章なので省けば良いのになと思いました。笑

2021年3月8日 ~ 14日 振り返り

先週の振り返り。

プライベート

AWS Certified Solution Architect Professionalの試験が月末にあり、それに向けて試験勉強をしていることが多かったです。

AWSのドキュメントを読んだりするのはそこまで苦ではないのですが、明らかに今後も絶対使わないだろうというものを試験のために覚えるというのがどうも苦手みたいです。。。

割り切って頑張ってこう。

読書

忙しいビジネスマンでも続けられる 毎月5万円で7000万円つくる積立て投資術

インデックス投資に関する本。

毎月5万円、ボーナス時には追加で20万円、合計100万/年をインデックスファンドに投資するというものです。

まず、投資の前に自分、もしくは家族にとって必要不可欠な出費とは何か考えろと書かれていたのがすごく良いなと思いました。

7,000万という数字は著者が考える夫婦1組で老後25年で最低限必要な支出の総額で、公的年金がどれぐらいもらえるか支出はどれぐらいになるかは個々人の問題となるので、老後にどれぐらい必要なのかは自分で計算した方が良さそうです。

どれぐらいの額が老後に必要なのか、それをどのようにして賄うのか、これをちゃんと考えていくことが大切なんだと思います。

貯蓄・投資し過ぎで、今の自分にお金を掛けられないのももったいないことなので。。。

  • 人生の出費に「優先順位」を付ける
  • 積み立て貯蓄は元本を保証してくれて安全なように見えるがインフレ率のことも考える必要がある
    • 物価上昇に弱い
  • リタイアした夫婦1組の生活費平均が23.7万/月
    • 生活最低限必要な支出
  • 最低限必要な支出 + 趣味や生きがいに使うお金を含めて35万/月と計算した場合
    • 35万 * 12ヶ月 * 25年 => 1億500万
    • そのうち公的年金で毎月10万補助される前提で計算をすると、1億500万 - (10万/月 * 12ヶ月 * 25年) => 7,000万円を補う必要がある
  • 出口戦略
    • プライベート年金の引き出しは金額ベースではなく、パーセンテージで行う方が合理的
    • 期待収益率に対して引き出し率をどれぐらいとするか

やったこと

nakanoshima.dev#14 JVM Langs Night Talkにオンライン参加しました。

スピーカー方の発表はどれも面白かったんですが、個人的に立野さんの「Scala と AWS でフルサーバーレスなプロダクト開発事例(仮)」というテーマがかなり刺さりました。

Scalaで書かれたLambdaの起動を早くするためにGraal VM Native Imageを利用してネイティブ化するというところが大変そうだけどすごいな!と思いました。

立野さんの発表資料は以下になります。

speakerdeck.com

イベント登壇された方の資料一覧はこちら。

nakanoshima-dev.connpass.com