OAuth2.0、JWT 入門 / Introduction to OAuth2.0 and JWT

Googleスライド版：https://docs.google.com/presentation/d/1bMLEPHaKGSxHMBtE1CR_8skVsXz7n9EJ9PICzOAZEKY/edit?usp=sharing

参考資料
・マスタリングAPIアーキテクチャ - 7章 APIの認証と認可
　　James Gough、Daniel Bryant、Matthew Auburn 著、石川 朝久 訳 (ISBN: 978-4-8144-0089-8)
・Amazon Cognito とは - Amazon Cognito
・OAuth 2.0 とは何か、どのように役立つのか？ - Auth0
・RFC 6749 - The OAuth 2.0 Authorization Framework
・JSON Web Token Introduction - jwt.io
・RFC 7519 - JSON Web Token (JWT)
・RFC 7515 - JSON Web Signature (JWS)
・RFC 7516 - JSON Web Encryption (JWE)

Transcript

1. OAuth 2.0、JWT 入門 2024/01/22　社内LT会 Ryo Ichiki
2. 目次 • 背景 • 認証と認可についておさらい • 認証と認可の整理 • OAuth2.0って何？ • OAuth2.0の例 • OAuth2.0の登場人物 • OAuth2.0の仕組み • JWTって何？ • JWTの構成 • JWTのクレーム (claim) について • 予約クレームの例 • 予約クレームの意味 • JWTのセキュリティについて • JWTの検証について • おわりに • 参考資料
3. 背景 Amazon CognitoやAuth0などの認証・認可プラットフォームを活用する場合、それらの ドキュメントをきちんと読めばある程度は良い感じに扱えてしまう。 しかし、ドキュメントには必ずと言って良いほどOAuth2.0、JWT、OIDCといったワードが 出てくる。 ユーザーの認証・認可プロセスを司る技術であるので、セキュリティ的にもこれらの技術 を正しく理解して扱うことが重要であると考える。
4. 認証と認可についておさらい 認証とは、ユーザーが「誰であるか」身元 (Identity) を確認する行為。 認可とは、認証されたユーザーに対し、「何ができるか」許可を確認する行為。 英語の文書では、認証(Authentication)をAuthN、認可(Authorization)をAuthZと表現する ケースがある。
5. 認証と認可の整理 項目 認証 (Authentication) 認可 (Authorization) 目的 ユーザーの身元確認 アクセス権の付与や制御 対象 ユーザーやシステム 操作やアクセス対象 データ例 ユーザー名、パスワード、 トークン、証明書 権限レベル、ロール、ポリシー
6. OAuth2.0って何？ 第三者アプリに対して、ユーザーの認証情報(ID, パスワードなど )を共有せず に、 その第三者アプリがユーザーのデータにアクセスすることを ユーザーの同意によって 可能にする 、トークンを利用した認可フレームワーク (プロトコル )。 RFC 6749で定義されている。
7. OAuth2.0の例 例えば、Googleアカウントを使って外部アプリ (NotionとかSpotifyとか) にログインする ときに、Googleアカウントのどのデータを外部アプリに共有するか同意を求められるア レ (超ざっくり)。
8. OAuth2.0の登場人物 (4つのロール) 1. リソースオーナー 保護されたリソースの所有者。リソースへのアクセスを承認する人物。 (ユーザー) 2. クライアント リソースオーナーの承認を得て代わりに保護されたリソースへのリクエストを行うアプリケーション。 (Amazon Cognitoで言うところのユーザープールのアプリケーションクライアントが該当する ) 3. 認可サーバー クライアントにアクセストークンを発行するためのサーバー。 (Amazon Cognitoのユーザープールがこの認可サーバーに該当すると思われる ) 4. リソースサーバー リソースオーナーの保護されたリソースをホスティングするためのサーバー。 (自分たちが作成するバックエンド APIなどが該当する)
9. OAuth2.0の仕組み (抽象化プロトコルフロー) クライアント (アプリ) リソースオーナー (ユーザー) 認可サーバー (Amazon Cognitoなど) リソースサーバー (API) (1) 保護されたデータへのアクセス許可を要求 (2) 同意を表す認可グラントを受け取る (3) 認可グラントを使ってアクセストークンを要求 (4) アクセストークンを受け取る (5) アクセストークンを使ってデータを要求 (6) 保護されたユーザーのデータを受け取る ※主語はすべてクライアント
10. JWTって何？ JWT (“jot (ジョット)”と発音) の正式名称はJSON Web Token。 JWTは、RFC 7519で定義されているトークン形式。 OAuth2.0の事実上の標準トークンとして使われることが多い。 JSONはXMLよりも無駄が少なく、エンコードするとサイズも小さくなる。 JWTはSAMLよりコンパクトなので、HTTPリクエストのAuthorizationヘッダーなどで情報 を転送する際にかなり有用。
11. JWTの構成 JWTはヘッダー、ペイロード、署名の 3つの部分で構成される。 各部分はBase64 URLエンコードされ、ドットで区切られた形式となる。 • ヘッダー トークンのタイプ(通常はJWT)と署名アルゴリズム (SHA256やRSAなど) で構成されるJSONオブジェクト。 • ペイロード クレーム (claim) と呼ばれる情報を含むJSONオブジェクト。 • 署名 ヘッダーとペイロードの組み合わせを署名したもの。 ヘッダーで指定された署名アルゴリズムが使われる。
12. JWTのクレーム (claim) について クレームとは、トークン内の情報を表すキーと値のペアのこと。 iss, sub, aud, exp, nbf, iat, jtiといったクレームがRFC 7519で予約されている。 これらの予約クレームには特別な意味がある。 しかし、トークン内で必須というわけではない。 最低限の情報を提供する出発点として機能する。
13. クレームの例 { “iss”: “https://example.com/”, “sub”: “123e4567-e89b-12d3-a456-426614174000”, “aud”: “ABC Service”, “exp”: 1737525600, “nbf”: 1737524400, “iat”: 1737524400, “jti”: “aaa7f211-5e15-43f6-9389-e5468918dcb6”, “username”: “ryichk”, “scope”: “openid profile email” }
14. クレームの例 { “iss”: “https://example.com/”, “sub”: “123e4567-e89b-12d3-a456-426614174000”, “aud”: “ABC Service”, “exp”: 1737525600, “nbf”: 1737524400, “iat”: 1737524400, “jti”: “aaa7f211-5e15-43f6-9389-e5468918dcb6”, “username”: “ryichk”, “scope”: “openid profile email” } 予約クレーム
15. 予約クレームの意味（１） • iss (Issuer) トークンの発行者 (Authority)。(例：Amazon Cognito、Auth0) • sub (Subject) ユーザーとして一意の識別子。特定の形式に従う必要はない。(例：UUID) システム内だけで一意か、グローバルで一意かを決定する必要がある。 • aud (Audience) トークンの利用を想定した対象者。
16. 予約クレームの意味（２） • exp (Expiration time) トークンの有効期限。 • nbf (Not before) トークンの開始時刻。この時間よりも前に利用してはいけない。 • iat (Issued at) トークンの発行時刻。トークンの開始時刻と必ずしもは一致しない。 • jti (JWT ID) JWTの一意な識別子。
17. JWTのセキュリティについて JWTには2つのセキュリティメカニズムがある。 • JWS (JSON Web Signature) - RFC 7515 JWTに署名を追加することでデータの改ざんを防ぐ。 トークンの内容は誰でも見ることができ、変更も可能だが、署名によって保証される。 発行後にトークンの内容が変更された場合、そのトークンは無効になることを意味する。 • JWE (JSON Web Encryption) - RFC 7516 JWTを暗号化することによってデータの機密性を担保する。
18. JWTの検証について JWTで最も一般的に使われるセキュリティメカニズムはJWSである。 JWSのデジタル署名は秘密鍵を使って行われる。 受信者は公開鍵を使ってトークンを検証する。 JWSだけを使っている場合はトークン内に機密データを含めてはいけない。 機密データを含めたい場合はJWEを使って暗号化する必要がある。
19. おわりに 現代のアプリケーションに欠かせない認可フレームワークであるOAuth 2.0とその仕組 みを支える技術として使われることが多いJWTについてご紹介しました。 タイトルに入門と記載した通りOAuth 2.0もJWTもこれで全てではありません。 どちらも奥深い技術であり、もっともっと深掘りできる内容があります。 他にもOIDCやSAML2.0、PKCEといった関連技術についても取り上げたいなと思ってい たのですが、時間の都合上あきらめました。 気になる方はこれを機にぜひ調べてみてください。
20. 参考資料 ・マスタリングAPIアーキテクチャ - 7章 APIの認証と認可 　　James Gough、Daniel Bryant、Matthew Auburn 著、石川 朝久 訳 (ISBN: 978-4-8144-0089-8) ・Amazon Cognito とは - Amazon Cognito ・OAuth 2.0 とは何か、どのように役立つのか？ - Auth0 ・RFC 6749 - The OAuth 2.0 Authorization Framework ・JSON Web Token Introduction - jwt.io ・RFC 7519 - JSON Web Token (JWT) ・RFC 7515 - JSON Web Signature (JWS) ・RFC 7516 - JSON Web Encryption (JWE)