OIDC は難しい

今日は （オンライン開催）OAuth & OIDC 勉強会 【アクセストークン編】 を受講。

リソースサーバー、認可サーバーという言葉を認証周りを作ってても使ってないのがよくないなー。

以下メモ。

• Authorization ヘッダーの Bearer にアクセストークンを設定
  • アクセストークン自体を Base64Url エンコードしてはだめ
• RFC6750 より、アクセストークンが無効のときは WWW-authenticate ヘッダーでエラーを返す
• jti を認可サーバー側に保存
• 署名手続き
  • 認可サーバーは秘密鍵を用いてアクセストークンに署名
  • リソースサーバーは公開鍵を落ちいて署名を検証
  • リソースサーバーは何らかの方法で公開鍵を取得する必要あり
  • 認可サーバが自身のJWK Setを公開するエンドポイントを提供
• 即時失効を諦めない限り内包型アクセストークンを採用する利点はほぼない
• Proof of Posession
  • 使用時にアクセストークンの正当な所有者であることの証明
  • アクセストークンを切符とすると
    • 電車の切符：拾った人でも誰でも使える
    • 国際線の航空券：使用時に本人確認あり
• Push Authorization Request for OAuth 2.0
  • 通称RAR
  • 認可リクエストの詳細を事前登録可能
    • 氏名などなど

途中から理解が追いつかなくなっていった。 ところで、トークンに含まれるユーザー属性情報群は、クレーム(claim) と呼ばれるけど、要求って意味が語源なのかな。