OAuth 2.0

※認証ではなく、認可

OAuth 2.0のプロトコルフロー

• A.まずクライアントがリソースオーナーに認可要求（Authorization Request）を出す。図ではクライアントがリソースオーナーに直接要求を出しているが、認可サーバー経由で間接的に要求する事がのぞましい
• B.リソースオーナーは認可要求を許諾する旨の返答として認可グラントをクライアントに送る。これも認可サーバー経由で行う事がのぞましい
• C.クライアントは認可サーバーに認可グラントを送ることでアクセストークンを要求
• D.認可サーバーはクライアントの認証と認可グラントの正当性の検証を行い、問題なければアクセストークンを発行
• E.クライアントはアクセストークンにより認証を受けることで、保護されたリソースへのアクセスをリクエスト
• F.アクセストークンが正当なら、クライアントのリクエストを受け入れる

認可グラントにはその発行の方法

JWT = JSON Web Token

構成

Header

JWTの基本情報が記載されている

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "SSQdhI1xxxxxxxxxxxxxxxxxxx",
  "kid": "SSQdhI1xxxxxxxxxxxxxxxxxxx"
}

他にjku(JWK セット URL)、jwk(JSON Web キー)、x5u(X.509 URL)、x5c(X.509 証明書チェーン)、x5t#S256(X.509 証明書 SHA-256 Thumbprint)、cty(ペイロードのメディアタイプ)、crit(必須パラメーター群指定)があるがこのPJでは使用しなし。

Payload

JWTの有効期間、クレーム、ユーザー情報などが記載されている

{
  "aud": "xyxz-xyxz-xyxz-xyxz-xyxzxyxzxyxz",
  "iss": "https://sts.windows.net/xxxxx-xxxx-xxxx-xxxx-xxxxx/",
  "iat": 1518766096,
  "nbf": 1518766096,
  "exp": 1518769996,
  "aio": "xyzxyz/c/wuX/xyzxyzxyzxyz/xyzxyzxyzxyzxyzxyzxyzxyz",
  "amr": [
    "wia"
  ],
  "family_name": "fName",
  "given_name": "gName",
  "ipaddr": "xxx.xxx.xxx.xxx",
  "name": "fName gName",
  "nonce": "xxxxyyy-wxyz-wxyz-wxyz-xyzxyzxyzxyz",
  "oid": "xxxxyyy-wxyz-wxyz-wxyz-xyzxyzxyzxyz",
  "onprem_sid": "S-1-5-21-xxxxxx-xxxxxxxx-xxxxxxx-xxxxxxx",
  "sub": "kBIE6ZBOnnbOI-7r70Y-TkcFefl4mc-TH00AM1OOyzQ",
  "tid": "xxxxyyy-wxyz-wxyz-wxyz-xyzxyzxyzxyz",
  "unique_name": "fname@sample.com",
  "upn": "fname@sample.com",
  "uti": "xyzxyzxyzxyzxyzxyzxyz",
  "ver": "1.0"
}

Signature

YyDuZVG3ORaRwEj1wHywCsYZMP6d6JcawkVXodzJTu_Wu1y2YxzlA4-XNdOGIzVMKiskroORaRwEj1wHywCORaRwEj1wHywCjIqdSgsg_m9yHNUZ6GK7l78nDBnCSci4BfV3OfcWjTis30QggkiCqfTp3ubaymyf8h2kVUPsBQcxWxjCiwOdPBG4W64m95tJORaRwEj1wHywCORaRwEj1wHywCBsii4JD5rlnlJjEkSr_AT4rF_y51ORaRwEj1wHywCE28UhjgzYtORaRwEj1wHywCORaRwEj1wHywCGo1qhVkzLMSbpxJHqHY_ORaRwEj1wHywCHOOhYORaRwEj1wHywCjtDg-escGmkinw

エンコード済のJWSヘッダとエンコード済のJWSペイロードをRSASSA-PKCS1-v1_5 using SHA-256アルゴリズムで署名したもの

クレーム

JSONオブジェクトで表現され、クレームセット内のクレームは一意でなければならない。

ヘッダと同様に、クレーム名が重複したJWTは拒否するか、ECMAScript 5.1 の節 15.12 (JSON オブジェクト) で定義されているとおり語彙的に最後の重複メンバ名だけを返却する JSON パーサを利用しなければならない。

JWTのクレームには予約済みクレーム名とパブリッククレーム名、プライベートクレーム名の3つのクラスが定義されている。

パブリッククレーム

JWTの利用者によって自由に定義できるが、衝突をさけるために、IANA JSON Web Token Claim Registry に登録するか、耐衝突性を持つ名前空間を含むパブリック名にすべきである。

プライベートクレーム

JWTの作成者と利用者の合意のものとで、予約済みでもパブリッククレーム名でもないプライベートクレーム名を用いてもよい。 ただし、衝突の可能性があるため、慎重に使用する必要がある。

参考

• https://tsmatz.wordpress.com/2016/03/08/azure-ad-msa-v2-endpoint-validate-id_token/
• https://openid-foundation-japan.github.io/draft-ietf-oauth-json-web-token-11.ja.html
• https://hiyosi.tumblr.com/post/70073770678/jwt%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E7%B0%A1%E5%8D%98%E3%81%AB%E3%81%BE%E3%81%A8%E3%82%81%E3%81%A6%E3%81%BF%E3%81%9F

1. 認可コードフロー

2. インプリシットフロー

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

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

5. リフレッシュトークンフロー

まとめ

参考

• https://authlete.com
• https://murashun.jp/blog/20150920-01.html
• https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f
• https://qiita.com/TakahikoKawasaki/items/4ee9b55db9f7ef352b47