見出し画像
Photo by lazy_planet

【メモ】 認証について（OAuth2.0/OpenID Connect）

sumi

OAuth2.0

RFC6749は4つの認可フロー（=アクセストークン発行手順）を定義している

  1. 認可コード

    1. 一時的に発行される認可コードをアクセストークンと交換

  2. インプリシット

    1. 認可エンドポイントからアクセストークンが直接発行される

  3. リソースオーナー・パスワード・クレデンシャルズ

    1. ユーザのidとpasswordをクライアントアプリに渡す

  4. クライアント・クレデンシャルズ

    1. ユーザ認証なし。クライアントアプリの認証のみ必要

  • リソースサーバ

    • User情報を持っている

  • 認可サーバ

    • アクセストークンを生成

    • クライアントに対して発行

  • クライアント

    • アクセストークンを元にリソースサーバーにリクエスト

OpenID Connect

  • Open Id プロバイダー

    • Idトークンを発行

  • クライアントアプリ

OpenID ConnectはOAuth2.0の上に作られたレイヤーなので似ている。

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.

OAuth2.0と似ているため、OpenIDプロバイダ 兼 認可サーバとすることが可能。
その場合はクライアントはIDトークンとアクセストークンをサーバに送る。

JWS

RFC 7515 JSON Web Signature
A.2. Example using response_type=id_token
ピリオドが2つあり、3つに分かれている

  • ヘッダ・・・黄色

  • ペイロード・・・緑

  • 署名(バイナリデータ)・・・ピンク

各部分はbase64urlでエンコードされている。
上記のidトークンをbase64urlでデコードするとJSONになる
eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ→{"kid":"1e9gdk7","alg":"RS256"}
alg → RS256（署名アルゴリズム）
他のkeyについてはRFC 7515仕様書を参考

RFC 7515(JWS)自体はペイロードがJSONでなくても良い。任意のバイナリデータ。

JWE

RFC7516 JSON Web Encryption
JWSと違いピリオドが4つあり5つに分かれている。

  • ヘッダー

  • 暗号化キー

    • Encrypted Key → 暗号化されたキー

    • 共有鍵を非対称鍵で暗号化する、二段階でキーを暗号処理しているため。

  • 初期ベクター

  • 暗号文

  • 認証タグ

BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)

RFC 7516: JSON Web Encryption (JWE)

  • 暗号化する側

    • 公開鍵を持っている。

    • 1.平文の暗号

      • 公開鍵から共有鍵をランダムに生成し、平文を暗号化する。

    • 2.共有鍵の暗号

      • 公開鍵を暗号化して共有鍵を生成する。

  • 複合化する側

    • 秘密鍵を持っている。

    • 暗号化する側から1,2を受け取る。

    • それぞれ複合化して平文を取得する。

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ をデコード → {"alg":"RSA-OAEP","enc":"A256GCM"}になる。
共有鍵の暗号アルゴリズムと平文の暗号アルゴリズムの2つがヘッダに入っている。

JWK

RFC7517 JSON Web Key

JWA

RFC7518 JSON Web Algorithms

JWT

RFC7519 JSON Web Token
JWS,JWEから拡張したもの。JWSのペイロード部分をJSONにすること。
OpenID ConnectはJWTをさらに拡張してIDトークンを定義。
JSON形式で表現されたclaim（クレーム）の集合をJWSもしくはJWEに埋め込んだもの。
（クレーム=key, valueの組みのこと）

  • JWS形式のJWT

    • ヘッダー、ペイロード、署名

  • JWE形式のJWT

    • ヘッダー、暗号化されたキー、初期ベクター、暗号文、認証タグ

署名したい場合はJWSを使い、暗号化したい場合はJWEを使う。
署名も暗号化もしたい場合は、JWSをJWEでくるむ（または逆）=Nested JWTと呼ぶ。

ID トークン

JWTの一種。
クレームの種類が仕様書に定義されている。

OpenID Connect は ID トークン を発行するための仕様。
fensiではリフレッシュトークンをやっていない
ユーザーはJWTから1日経っていたら、新しくJWTを発行している。

スキ頂けると嬉しいです〜