next-authを触ってみる

yuto-m

next-authを使ってOAuth認証させる方法知りたいので調査。
https://github.com/nextauthjs/next-auth-example をcloneして確認していく。

yuto-m

page routerぽいけど一応公式ドキュメントを読んだ。
そんなに難しくなさそう。
app routerのドキュメント欲しい。
公式見た感じ簡単だからpage routerでやろうかな。

yuto-m

page routerでやる。
とりまnpx create-next-app . --ts --use-npm testでnextのテンプレをpage routerで立てる。

yuto-m

下記のドキュメント通りに進めていく。

yuto-m

page routerの構造忘れたので後で見る

yuto-m

github appのドキュメント後で見る

yuto-m

簡単すぎワロた。

OAuth完了すると謎のバスが出る

yuto-m

vercelにデプロイしてOAuthするのと/src/pages/api/hello.tsのapi routesを認証済みかどうかで挙動を変更するのが続き。
googleアカウントでも認証してみる。
認証したユーザーをdbに登録したい。

yuto-m

jwt後で読む

yuto-m

~~本番でOAuthエラー出てるので直す~~
production用のドメインのcallbackを指定していなかったからだった。
本番でgithub使用してログインできるようになった。

yuto-m

でもこれってgithubのapiとかidとかどうやって取得するんやろか。
~~getServerSessionで取得できるsession情報を見ても下記しかないからあんまり意味なくないかっていう。~~

callbackで取得するぽい。

{
  user: {
    name: 'Yuto Miyakawa',
    email: undefined,
    image: 'https://avatars.githubusercontent.com/u/43704306?v=4'
  },
  expires: '2023-12-21T12:49:56.559Z'
}

yuto-m

取得したaccessTokenで下記のライブラリ初期化したらgithubのapi叩けるとこまでできた。
あとは取得したデータ使って何するかっていう感じだからもう終わりで良いかなっていう。

yuto-m

accessTokenをクライアントに渡すのって若干不安がある気がするが、ちゃんと扱えれば大丈夫らしい。

yuto-m

sessionの扱いは2パターンあってjwtがデフォルトで、jwtはHttpOnlyかつサーバー側にのみあるkeyでencryptされてるから仮にjwtが盗まれてもdecryptされないので安全て書いてあった。

Auth.js libraries can create sessions using JSON Web Tokens (JWT). This is the default session strategy for Auth.js libraries. When a user signs in, a JWT is created in a HttpOnly cookie. Making the cookie HttpOnly prevents JavaScript from accessing it client-side (document.cookie), which makes it harder for attackers to steal the value. In addition, the JWT is encrypted with a secret key only known to the server. So even if an attacker were to steal the JWT from the cookie, they would not be able to decrypt it. Combined with a short expiration time, this makes JWTs a secure way to create sessions.

とはいえ、encryptedされたjwtトークンの内容が絶対にdecrpytされるという仮定はしない方が良いとも書いてあるのでやはりフロントに機密情報(ex. アクセストークン)を渡すのはちょっとリスク高い。

Even if appropriately configured, information stored in an encrypted JWT should not be assumed to be impossible to decrypt at some point - e.g. due to the discovery of a defect or advances in technology. Data stored in an encrypted JSON Web Token (JWE) may be compromised at some point. The recommendation is to generate a secret with high entropy.

ちなみにDBにsession idを保存するパターンもあるが、パフォーマンスを考慮するとJWTを使いつつJWTに秘密情報を含めない運用の方が楽そうではある。
ただ、JWTで実現が難しいログイン制限やログアウトしたら全ての端末からログアウトするみたいな機能を作りたいならDBの方が良いとのこと。

yuto-m

next jsのapi routeでendpoint増やす方法

getToken()はサーバーサイドのみで動く。

JWT callbackでtokenにアクセストークンを含めつつ、session callbackではアクセストークンを含めなければクライアント側でアクセストークンが触れる心配はなくなりそう。

安全のためにデフォルトだとtokenの一部しかフロントで扱えなくなってる

The session callback is called whenever a session is checked. By default, only a subset of the token is returned for increased security. If you want to make something available you added to the token (like access_token and user.id from above) via the jwt() callback, you have to explicitly forward it here to make it available to the client.

yuto-m

jwtてどのユーザーが、どのjwtに紐づいているかってどうやって分かるんだろうか。
sessionならsession idだけど、それぽいのがついてるんだろうか。

yuto-m

sendgridも触ってみたかったのでemail authも試す。
dbがいるぽい。

yuto-m

sendgridのアカウントがなぜか作れなくて死亡した。
company nameとかをnoneにしたから？

別のgmailアカウントでアカウント作ってみたので承認されるまで待ち。

yuto-m

承認されないので終わり