OAuth 徹底入門

11章

OAuthではトークンの中身をどうするのかについてはまったく言及していない。 トークンなしでは、OAuthは成り立たない。
しかし、OAuth2.0認可フレームワークの仕様では、トークン自体の構成に言及していない。
これは、トークン自体がどうあるべきかを特定しないことで、異なる特徴やリスクの特性、およびさまざまな要求を伴う多種多様な状況の中でOAuthが機能できるようにするため。

OAuthはこの柔軟性とモジュール性によって、ほかの包括的なセキュリティ・プロトコル（たとえば、WS*、SAML、Kerberosなど、トークンのフォーマットが指定されておりシステムを構成するすべての要素がそのフォーマットについて把握することを強いられるプロトコル）では実現が難しかったケースにも適用できるようになっている。

トークンを小さくすることのメリット

認可サーバーではトークンを生成した際に、そのトークンの値をディスク上の共有データベースに格納していました。
保護対象リソースがクライアントからトークンを受け取ると、そのトークンに関する情報をその同じデータベースから検索し、そのトークンが何に対して有効なのかを見つけ出していました。
このトークンは内部に何も情報を持っておらず、データ検出のためのたんなる識別子として機能していました。このことには何も問題はなく、アクセス・トークンの生成と管理においてとくに変わった手法でもありません。この手法のメリットはトークン自体のサイズは小さく保ちつつ、生成するトークンの文字列をさらに乱雑にできるというメリットがあること、

JWTの必要性

共有DBでの検索を必要としない代わりに、必要な情報をすべて内部に持っている情報をトークンに詰め込む。
この仕組みを実現できるのがJWT

JWTの仕組み

JWTの中核となるのは JSONオブジェクト でありネットを介して送信するためにフォーマットしたもの
ドットの値はランダムな文字列ではなく、JSONオブジェクトを Base64URLエンコード したもの。

• Base64の理由 JWTが通常どこに設定されているのかによって変わる（HTTPヘッダーなのか、クエリー・パラメーターなのか、formパラメーターなのか）
  さまざまなデータベースやプログラミング言語の文字列なのかなど）によって変わります。これらの設定場所ではそれぞれ限られた文字しか扱えないようになっており、何らかのエンコードをすることなしには使えない。
  そのため最初から Base64URLエンコード を使うことで新たにエンコードすることなく上記の共通の設定場所ならどこでも使用できるようにする。

JWTの仕様

expireは秒で指定しなければいけない。