【書評】パスキーのすべて

概要

パスキーのことを知りたいと思って購入。

#PR

プロになるJava-仕事で必要なプログラミングの知識がゼロから身につく最高の指南書

まず、内容がわかりやすい。

難しい説明を極力使わずに内容をかみ砕いて説明してくれている。

ユースケースや実装例も豊富で、巷で見かけるパスキーのユースケースは一通り網羅されていると思う。

ユーザーがパスキーを紛失したときの対処法など、実務で考慮すべきポイントもしっかりと押さえられている。

第8章ではやや専門的な内容も扱っており、パスキーを深堀りしたい読者にも満足できる内容になっている。

全体的に丁寧で自分のような初心者にはおすすめの一冊だと思う。

自分は実務でパスキーを実装するにあたって本書を購入したのだが、実務ではしばしば本書に書かれていない知識を必要とする場面があった。

例えばapple-app-site-associationやassetlinks.jsonについては本書では触れられていないが、実務でモバイルアプリにパスキーを組み込もうと思ったらほぼ100%知っておかなければならない。

他にもブラウザでパスキーの動作確認をする方法なども本書では解説されていない。

ローカルでパスキーの動作確認をするときにはRP IDをlocalhostにしないといけないとか、デベロッパーツールから仮想認証機を有効化しないといけないとか、意外と罠が多い。

初心者は絶対引っかかるので(自分は引っかかった)、そういう部分の解説がもう少し豊富だったら良かったかなと思う。

例えばclientDataJSONについて索引を引こうとして「C」のページを引いても、なぜか引っかからなかった。

結論から言うと以下のような索引になっていた。

【A】
- AuthenticatorAttestationResponse … 129
  - attestationObject … 130
  - clientDataJSON … 130

clientDataJSONを引くために、AuthenticatorAttestationResponseを引く人なんているんだろうか？

単純な疑問なのだが、以下のような索引では駄目なんだろうか？行数は変わらない訳だし。

前者のほうが構造化されていて美しいという感覚は分かるが、別に索引が構造化されている必要は無い気がする。

出版に関する知識が皆無なので、もしかしたらこれは素人の意見なのかもしれない。

でも実際に業務で索引を引こうとして困ったのである。仮に出版業界ではこれが正しいのだとしても、自分は間違っていると思う。

丁寧な内容で分かりやすい。

本書を読んで「全然意味がわからん」みたいになる人はほぼいないと思う。

一方で一部内容が不足している部分もありそうなので、適宜ネットで情報を補完しながら読むのがおすすめかなと思う。