home ホーム search 検索 -  login ログイン  | reload edit datainfo version cmd icon diff delete  | help ヘルプ

技術/Security/OAuth

技術/Security/OAuth

技術 / Security / OAuth
id: 1074 所有者: msakamoto-sf    作成日: 2012-04-16 00:23:54
カテゴリ: OAuth セキュリティ 

OAuth勉強用リンクメモ。

実装

OAuth 1.0 仕様, 参考資料

OAuth 2.0 及び関連RFC

JSONによる暗号処理関連:

アサーション, SAML, JWT との関連:

PKCE関連:

Proof of Posession (PoP: 所有証明)

OpenID Connect:

OAuth 2.0 参考資料

参考書籍

簡単な読書メモ(間違ってる可能性もあるので参考程度に)

  • フロント・チャネル / バック・チャネル : フロントがリソース所有者とブラウザを介したコミュニケーション。バック・チャネルはリソース所有者を介さない、ソフトウェアだけのコミュニケーション。
  • "Bearer" : この場合、小切手や手形の「持参人」としての意味っぽい。運ぶ人、運搬人、あるいは手紙の使者という意味も持つ。ニュアンス的には、「中身が何かは知らないけど、とりあえず重要な情報を持ってきた人」的な感じになると思う。
    • OAuth 2.0 における Bearer トークンのポイントとして、「クライアントはトークンの中身を解析しない/する必要が無い/できない」というのがある。認可サーバから発行されたトークンを、まさに「中身を知らずにとりあえず持参して運んできた人」がクライアント、という見立てっぽい。
  • クライアントは Bearer トークンの中身を知らなくても、保護対象のリソースサーバは知る必要がある場合もある。特に認可サーバとリソースサーバとで、認可した主体やスコープ、有効期限など細かくやり取りしたい場合。
    • → 認可サーバが発行するトークンの中身を、JSONを使って表現力を高め、さらに署名などの暗号技術を組み合わせることでセキュリティを確保する、そのためにJWS/JWTなどが活用される。
  • ただし Bearer トークンの中身にいろいろ詰め込みすぎると、トークンが漏洩したときの影響が大きくなる。リソースサーバが、アクセストークンをもとに認可サーバに対してトークンの詳細をリクエストする仕組みが「トークン・イントロスペクション」として策定された。
  • 構成時シークレット(Configuration Time Secret) : ソフトウェアを構成する際に組み込まれるシークレット。クライアントID/クライアント・シークレットなど。
  • 実行時シークレット(Runtime Secret) : ソフトウェア実行時に生成・取得されるシークレット。認可コードやアクセストークン/リフレッシュトークンなど。
  • 公開クライアント(Public Client) : クライアント内に構成時シークレットを持つことができない。ネイティブアプリやブラウザ内で完結するアプリケーションなど。これらにクライアントシークレットを埋め込んでも、解析されて容易に取り出されてしまい、秘密のままにできない。
    • 公開クライアントでの認可コード付与方式での認可コードとトークンのセキュリティを強化するために、PKCE(Proof Key for Code Exchange) が開発された。認可コード発行時と、アクセストークンへの交換時に、クライアントが生成したchallenge/verifier を認可サーバとやり取りすることで、認可コードの横取りを防ぐ。
  • 機密クライアント(Confidential Client) : 構成時シークレットを保持できる。Webアプリとしてのクライアントなど。
  • ネイティブアプリはコピーされて複数の場所で動くことから、クライアントシークレットを保持できず、クライアントの認証に難があった。
    • → 実行時にクライアントを動的に認可サーバに登録し、認可サーバ側でクライアントシークレットを発行・管理する仕組みが開発された。これはクライアントからの自己申告的な側面も強いように思われ、認証というよりは、同じクライアントIDに基づく複数のクライアントインスタンスを「識別」するためのもの、と考えたほうが良いかも。
  • OAuth が「認証」ではないのはなぜか?
    • そもそも OAuth におけるアクセストークンは、所有者が認可したあとは、所有者がいてもいなくても使える性質がある。grant type によってはそもそもシステム同士の認可だったりして所有者がいない場合すらある。
    • 認可サーバにおいて認可を下す瞬間に、所有者の認証が行われる保証は厳密には無い。システムによる自動作業の可能性もあるし、そこはブラックボックスであり OAuth の範囲外。
    • つまりアクセストークンがあること、イコール、そのアクセストークンに紐づく「誰か」が認証されたこと、という紐付けは OAuth 2.0 の範囲では取り扱っていない。
    • さらに言えば、アクセストークンのライフサイクルと、「認証」情報のライフサイクルが異なる。また、OAuth 2.0 の思想としてクライアント側はアクセストークンの中身を認知しないため、アクセストークンに認証情報を埋め込み認可サーバからクライアントに情報を伝えるのはできない。
    • → ここにおいて、認可サーバからクライアントに、「認証」イベントの発生と認証情報を伝えるための、アクセストークンとは別のライフサイクルを持ったトークンが必要とされる。これが OpenID Connect における IDトークンとなり、表現力とセキュリティを要求されることからJWTエコシステムの技術が使われている。
  • Bearer トークンはクライアントが中身を知らなくても良い反面、漏洩してしまった場合にクライアントとトークンを紐付けるのが難しい問題がある。(中身を知らなくても使える = 攻撃者の手に渡っても使える)
    • これを解決するために、鍵(公開鍵ペア)をトークンをペアにして、クライアント側でトークンと鍵による署名を追加し、保護対象リソース側で検証することによりクライアントとトークンを紐付けられるようにしたが「Proof of Posession : 所有証明」の仕組みっぽい。

全体的にOAuth 2.0を幹とした関連仕様/技術が広がっているが、その関連仕様はなぜ作られたのか、OAuth 2.0だけでは解決できないどのような問題を解決しようとしているのか、またそのためにどういう技術を使っているのか、というのが分かりやすく書かれているのが良かった。
また実際に動く簡易的なシステム一式をJavaScriptのサンプルコードで示し、OAuth 2.0や関連仕様のエッセンスをソースコードで解説してくれるのもユニークであり、またポイントを押さえた解説がありがたい。
おそらく原著の影響と思われるが文章がやや冗長なところはあるものの、2019年時点で OAuth およびそのエコシステムをここまで包括的に解説してくれる書籍は貴重。
今から始めると用語だけでも迷子になりそうな OAuth エコシステムの世界で、分かりやすく整理された道標を示してくれる一冊となっている。



プレーンテキスト形式でダウンロード
現在のバージョン : 2
更新者: msakamoto-sf
更新日: 2019-05-03 00:38:45
md5:88573ca2d8c3acbf00790a1861943126
sha1:93d25b15612aa321cf85e13411d7fa31da7dfdec
コメント
コメントを投稿するにはログインして下さい。