OAuth 2.0

参考:

OAuth Community Site (oauth.net)

Code | OAuth (oauth.net)

oauth-xx – GitHub

概要

参考:

一番分かりやすい OAuth の説明 – Qiita

OAuth 認証を真面目に考える | DevelopersIO

OAuth 2.0 の仕組みと認証方法 | murashun.jp

多分わかりやすい OAuth | SIOS Tech. Lab

アプリ開発で知っておきたい認証技術 OAuth 1.0 + OAuth 2.0 + OpenID Connect | SlideShare

OAuth 認証

参考:

「OAuth 認証」を定義しよう | OAuth.jp

非技術者のための OAuth 認証 (?)と OpenID の違い入門 | @_Nat Zone

OpenID Connect

参考:

OpenID Connect ユースケース、OAuth 2.0 の違い・共通点まとめ | Build Insider

OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita

OAuth2 や OpenID Connect とは何か、なんとなくわかった気になるための概要メモ | 備忘録の裏のチラシ (norikone.hatenablog.com)

ユースケース

Web アプリ

  • secret (= クライアント ID に対応するパスワードなどのクレデンシャル情報) を秘匿に保てる
  • (バッチ処理など) 比較的長期間有効な API アクセス権限を必要とする場合がある

ネイティブアプリ (アプリ独自の Backend Server なし)

  • secret を秘匿に保てない
  • 初回起動時以外はログインさせることもないので、長期間有効な API アクセス権限を必要とする
  • 端末は特定ユーザーと1対1でひも付くことが想定されるため、ユーザー認証の重要性は低い

ネイティブアプリ (アプリ独自の Backend Server あり)

  • secret を秘匿に保てない
  • 初回起動時以外はログインさせることもないので、長期間有効な API アクセス権限を必要とする
  • バックエンド側では全ユーザーのデータを管理しているため、バックグラウンドではユーザー認証が必要

JS アプリ (アプリ独自の Backend Server なし)

  • secret を秘匿に保てない
  • 常にユーザーがブラウザーの前にいることが期待できるため、必要に応じて API アクセス権限を再取得可能
  • ブラウザーは特定ユーザーと1対1でひも付くことが想定されるため、ユーザー認証の重要性は低い

JS アプリ (アプリ独自の Backend Server あり)

  • secret を秘匿に保てない
  • 常にユーザーがブラウザーの前にいることが期待できるため、必要に応じて API アクセス権限を再取得可能
  • バックエンド側では全ユーザーのデータを管理しているため、バックグラウンドではユーザー認証が必要

参考:

OAuth 2.0 の代表的な利用パターンを仕様から理解しよう | Build Insider

クライアントタイプ | The OAuth 2.0 Authorization Framework (openid-foundation-japan.github.io)

アクセストークン

実装タイプ

  • 識別子型
  • 内包型 (JWT / JSON Web Token)
  • ハイブリッド型

署名アルゴリズム (JWT)

  • 対称鍵 (共有鍵方式)
  • 非対称鍵 (秘密鍵・公開鍵方式)

参考:

OAuth アクセストークンの実装に関する考察 – Qiita

認可レスポンス

code
必須 (REQUIRED). 認可コードは認可サーバーによって許可される. 漏洩のリスクを軽減するため, 認可コードは発行されてから短期間で無効にしなければならない (MUST). 認可コードの有効期限は最大でも10分を推奨する (RECOMMENDED). クライアントは2回以上認可コードを使用してはならない (MUST NOT). もし認可コードが2回以上使用された場合は, 認可サーバーはリクエストを拒否しなければならず (MUST), この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである (SHOULD). 認可コードはクライアント識別子とリダイレクト URI に紐づく.
state
クライアントからの認可リクエストに state パラメーターが含まれていた場合は必須 (REQUIRED). クライアントから受け取った値をそのまま返す.

参考:

認可レスポンス | The OAuth 2.0 Authorization Protocol (openid-foundation-japan.github.io)

refresh_token

参考:

refresh_token で access_token を再発行した時の挙動について | teratail

トークン置換攻撃

参考:

単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone

OAuth 2.0 Implicit Flow をユーザー認証に利用する際のリスクと対策方法について | r-weblife

「OAuth 2.0 (Implicit Flow) でログイン」の被害例 | OAuth.jp

Is the OAuth 2.0 Implicit Flow Dead? | Okta Developer

CSRF 対策

参考:

クロスサイトリクエストフォージェリ | The OAuth 2.0 Authorization Protocol (openid-foundation-japan.github.io)

クリックジャッキング

参考:

クリックジャッキング | The OAuth 2.0 Authorization Protocol (openid-foundation-japan.github.io)

The OAuth 2.0 Authorization Framework

参考:

OAuth 2.0 全フローの図解と動画 – Qiita

Authorization Flow

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

参考:

Yahoo! ID 連携 Authorization Codeフロー | Yahoo! デベロッパーネットワーク

Authorization Code Grant – RFC 6749 The OAuth 2.0 Authorization Framework | IETF (tools.ietf.org)

Implicit Flow

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

参考:

Implicit Grant – RFC 6749 The OAuth 2.0 Authorization Framework | IETF (tools.ietf.org)

PKCE

参考:

PKCE で防げる「認可コード横取り攻撃」とはどのような攻撃か – Qiita

認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと – Qiita

OAuth2.0 で認可コードの漏洩を防ぐ PKCE | 理系学生日記

Web API

参考:

第二弾 OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita

Tips

参考:

OAuth & OpenID Connect の不適切実装まとめ – Qiita

タグ:

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です