技術/Security/OAuth

技術 / Security / OAuth

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

[ Prev ]
[ Next ]
[ 技術 ]

OAuth勉強用リンクメモ。

OAuth Community Site
- http://oauth.net/
OAuth - Wikipedia, the free encyclopedia
- http://en.wikipedia.org/wiki/OAuth

実装

2-legged OAuthによるAPIアクセス << mixi Developer Center (ミクシィデベロッパーセンター)
- http://developer.mixi.co.jp/appli/ns/mob/2-legged-oauth/
Obtaining access tokens | Twitter Developers
- https://dev.twitter.com/docs/auth/obtaining-access-tokens
OpenSocialのOAuthまとめ – Tender Surrender
- http://devlog.agektmr.com/ja/archives/79

OAuth 1.0 仕様, 参考資料

RFC 5849 - The OAuth 1.0 Protocol
- http://tools.ietf.org/html/rfc5849
2-legged vs. 3-legged OAuth - cakebaker
- http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/

OAuth 2.0 及び関連RFC

RFC 6749 - The OAuth 2.0 Authorization Framework
- https://tools.ietf.org/html/rfc6749
RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
- https://tools.ietf.org/html/rfc6750
RFC 6819 - OAuth 2.0 Threat Model and Security Considerations
- https://tools.ietf.org/html/rfc6819
RFC 7009 - OAuth 2.0 Token Revocation
- https://tools.ietf.org/html/rfc7009
RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol
- https://tools.ietf.org/html/rfc7591
RFC 7592 - OAuth 2.0 Dynamic Client Registration Management Protocol
- https://tools.ietf.org/html/rfc7592
RFC 7662 - OAuth 2.0 Token Introspection
- https://tools.ietf.org/html/rfc7662
RFC 8252 - OAuth 2.0 for Native Apps
- https://tools.ietf.org/html/rfc8252

JSONによる暗号処理関連:

RFC 7515 - JSON Web Signature (JWS)
- https://tools.ietf.org/html/rfc7515
RFC 7516 - JSON Web Encryption (JWE)
- https://tools.ietf.org/html/rfc7516
RFC 7517 - JSON Web Key (JWK)
- https://tools.ietf.org/html/rfc7517
RFC 7518 - JSON Web Algorithms (JWA)
- https://tools.ietf.org/html/rfc7518
RFC 7519 - JSON Web Token (JWT)
- https://tools.ietf.org/html/rfc7519
RFC 7520 - Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)
- https://tools.ietf.org/html/rfc7520

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

RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
- https://tools.ietf.org/html/rfc7521
RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
- https://tools.ietf.org/html/rfc7522
RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
- https://tools.ietf.org/html/rfc7523

PKCE関連:

RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
- https://tools.ietf.org/html/rfc7636

Proof of Posession (PoP: 所有証明)

https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/

OpenID Connect:

https://openid.net/connect/

OAuth 2.0 参考資料

OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT
- http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる : .Nat Zone
- http://www.sakimura.org/2012/02/1487/
OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon - r-weblife
- http://d.hatena.ne.jp/ritou/20120206/1328484575
「OAuth 2.0 (Implicit Flow) でログイン」の被害例 - OAuth.jp
- http://oauth.jp/oauth-20-implicit-flow
OAuthにおける「クライアントサイドに対する認可」なのか「サーバーサイドに対する認可」なのか明確でない問題 - 金利0無利息キャッシング – キャッシングできます - subtech
- http://subtech.g.hatena.ne.jp/mala/20120214/1329199851
OAuth 2.0でユーザーが認可をする"アプリケーション"とはサービス全体のことではない - r-weblife
- http://d.hatena.ne.jp/ritou/20120311/1331444771

参考書籍

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

フロント・チャネル / バック・チャネル : フロントがリソース所有者とブラウザを介したコミュニケーション。バック・チャネルはリソース所有者を介さない、ソフトウェアだけのコミュニケーション。
"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 エコシステムの世界で、分かりやすく整理された道標を示してくれる一冊となっている。