認証・認可について

一言でJWT（JSON Web Token）とは、以下のようなJSONデータをBase64エンコードしたもの

{
  "iss": "io.exact.sample.jwt",
  "sub": "saumple",
  "exp": 1670085336,
  "email": "sample@extact.io",
  "groups": "member, admin"
}

↓
ew0KICAiaXNzIjogImlvLmV4YWN0LnNhbXBsZS5qd3QiLA0KICAic3ViIjogInNhdW1wbGUiLA0KICAiZXhwIjogMTY3MDA4NTMzNiwNCiAgImVtYWlsIjogInNhbXBsZUBleHRhY3QuaW8iLA0KICAiZ3JvdXBzIjogIm1lbWJlciwgYWRtaW4iDQp9

yuta4j1

Base64への変換は、URLセーフな手段として用いられている

※ 余談として、Base64エンコードは以下のようなニーズがあるときに使用する。

バイナリデータのテキスト表現: Base64は、画像、音声、ビデオなどのバイナリデータをASCII文字列に変換する。テキストのみを扱えるシステムやプロトコルでバイナリデータを安全に送信できる。
電子メールの添付ファイル: 電子メールの規格（SMTP）は、本来テキストのみを送信するために作られており、画像や文書などの添付ファイルは、Base64エンコーディングによりテキストに変換される。
URLの一部としてのバイナリデータ: URLはASCII文字列でなければならないため、Base64エンコーディングはURLにバイナリデータ（例えば、画像やPDFのデータ）を埋め込むために使用される。
HTTPとデータのエンコーディング: HTTPヘッダーやクッキーはテキスト形式でなければならないため、Base64はここにバイナリデータを含めるための手段として使われる。
Web APIの認証: 一部のWeb APIでは、Base64エンコーディングを使用して認証情報（ユーザ名とパスワード）をエンコードする。

yuta4j1

OIDCでもOAuth2.0でも、ほとんどフローは一緒。
認証サーバーからID/パスワードが求められ、入力後問題なければ何らかのトークンが発行される流れは同じ。
OIDCはIDトークンを発行し、OAuth2.0ではアクセストークンを発行する。

OIDCは、認可サーバーの認可エンドポイントから返却されるresponse_typeのデータを拡張することで認証を実現している

yuta4j1

IDトークンは「いつ」「どこで」「なんのために」作られたかを検証する。アクセストークンは、これを検証しない。

アクセストークンはあくまで認可に使用されることを想定している。
一方認証には、上記のような発行元を検証することで悪意のあるユーザーを弾く仕組みが必要になるため、IDトークンの仕様が必要となる。
そういうことで、OAuth2.0は「認可」OIDCは「認証」という使い分けが必要。

https://www.sakimura.org/2012/02/1487/

yuta4j1