OAuth徹底入門の読書感想文 -6章-
OAuth徹底入門を読んだので感想と概要を書いていきます
5章については先日書きました
6章 実際の環境に置けるOAuth2.0
認可方式
1 - 5章では認可コードによってアクセストークンを払い出す方法でOAuthの仕組みを解説していたが、実際のサービスではそのほかにも様々な方法が用いられる
インプリシット付与方式
クライアントがブラウザの中でのみ存在するJavascriptで書かれたアプリケーションの時に主に使われる付与方式
ユーザーが認可画面でクライアントを認可すると、認可コードではなくアクセストークンが直接払い出される
クライアントクレデンシャルによる付与方式
リソース所有者が明確には存在しない、またはクライアント・アプリケーション自体がリソース所有者である場合に用いられる付与方式
クライアントは自身のクレデンシャル (クライアントIDとクライアント・シークレット)を送信し、アクセストークンを受け取る
リソース所有者のクレデンシャルによる付与方式 (アンチパターン)
基本的にはアンチパターンで出来る限り避けるべき付与方式
クライアントがリソース所有者のクレデンシャルを受け取り、それを認可サーバーに送信してアクセストークンを受け取る
一度アクセストークンが払い出されれば保護対象リソースとクライアントのやりとりにはアクセストークンが使用されるのでリソース所有者のクレデンシャルは使用されないので、クライアントがリソース所有者のふりをして毎回保護対象リソースへリソース所有者のクレデンシャルを送信するよりはまだまし
アサーションによる付与方式
SAML (Security Assertion Markup Language)かJWT (JSON Web Token)などのフォーマットで暗号学的な方法で保護されている要素 (アサーション)をトークンと交換する方式
クライアントはアサーションを提供者から受け取り、それを認可サーバーに送ることでアクセストークンを受け取る
クライアントの種類
ウェブアプリケーション
OAuthクライアントとして最初に考えられていたユースケース
フロントチャネルとバックチャネルの両方のコミュニケーションを活用できるので、認可コード、クライアントのクレデンシャル、アサーションによるフローを簡単に使うことができる
ブラウザ内アプリケーション
Javascriptなどで書かれた完全にブラウザ内で稼働するアプリケーション
サーバーを持たないため、インプリシット付与方式がもっとも良く適合している
ネイティブ・アプリケーション
デバイスにインストールして使用するタイプのアプリケーション
認可サーバーからブラウザにリダイレクトすることが可能なURIを提供することでフロントチャネルのレスポンスも受け取れるようになる
認可コート、クライアントクレデンシャル、アサーションによるフローを使用することが多い
感想
認可コードを用いたフローで今まで読み進めてきたので、急にその他の認可方式がいくつも出てきたが想像しにくいものもあった (クライアント・クレデンシャルとか)
ネイティブ・アプリではリダイレクト用のURIを用意しておくというのは以前chrome拡張とネイティブアプリのつなぎこみの際にmanifest.jsonにやった方式と同じだった
