gRPCの認可用Tokenについて

この記事の読者

• 私並みに頭悪い人
• メモ書きでも怒らない人

gRPCの認可について

gRPC使って何かやろうとした時、呼び出し元が悪者でも使えちゃうので
Tokenを払い出して、呼び出し時のHeaderにつけてもらおうっていう話になった。

でも、Tokenってどうやって作るんだ？
有効期限ってどうすんだ？

要約

• JWT(JSON Web Token)使うとセッション管理用テーブルが要らない
  • 有効期限を更新するとTokenを更新する必要がある
    • 何かアクションを起こす度、Tokenをもらうのは面倒
  • 割り切って有効期限を1日限定にしてしまえば、Tokenの変更はない
• セッション管理用テーブルを使う
  • Token払い出したら、セッション管理テーブルに有効期限(1時間後まで、とか)を入れる
  • アクセスがある度、セッション管理テーブルの有効期限を延ばす
  • Tokenの変更はない。

有効期限

Tokenに有効期限を設定しないと、盗まれた時いつまでも悪用されてしまう。
なので、有効期限を設定しておくと、万が一盗まれても被害を最小限に留めることが出来る。

JWT

JWTは Header Payload Signature の3要素を.で繋げて一つのTokenとする。
Payload部に有効期限を設定できる。こんな感じ。

payload

{
  "exp": 12345789
}

expに有効期限をUNIX時間で設定する。
Payload部を更新すると、Signature部も変わるのでToken全体に影響がある。
気軽に更新できない。

セッション管理テーブル（ZABBIXの場合）

ZABBIX APIはセッション管理テーブルとユーザテーブルで有効期限判定をしている

1. ログインAPIが叩かれるとUUIDを発行、クライアントに返す。UUIDがTokenになる
2. UUIDはセッションテーブルに保持。最終アクセス時間を同テーブルに入れておく。
3. クライアントから、別のAPIが叩かれた時、付与されてるUUIDを確認
4. UUIDがセッションテーブルにあれば、次
5. (ユーザテーブル.autologout + セッションテーブル.最終アクセス時間) < 現在時刻 であることを確認
6. セッションテーブル.最終アクセス時間を現在時刻で更新

まとめ

セッション管理とか基本中の基本なんだけど、先達の知恵やフレームワークに頼り切りで、よく分かってなかったなぁ、という。。
セッション管理用のテーブルを作るのが正解かな？

でも、もうJWTで実装しちゃった。。