はじめに
OAuth, SSL/TLSの概要を整理しました。
想定読者
- OAuth, SSL/TLSとはなんぞや？とりあえず概要のみ知りたい方
概要
OAuth
OAuth（オーオースと読む）とOIDCは似ているけど別物。
- 認可のフレームワーク
- 認可はユーザーのアクセス権限を確認すること
つまり、サードパーティアプリ（Xとか）によるHTTPサービス（Facebookとか）への限定的なアクセス権限を与える。
※ちなみにOIDC
- 認証のフレームワーク
- 認証はユーザーが誰であるかを確認すること
OAuthが必要な理由
サードパーティアプリにHTTPサービスのクレデンシャル情報(ユーザー名とかパスワード)を教える必要がない。
- サードパーティアプリに必要な権限のみ与えるため不要な操作を防ぐ
- サードパーティアプリが攻撃されてもHTTPサービスのクレデンシャル情報が漏れない
OAuthの流れ
- クライアント（サードパーティアプリ）から認可サーバ（OAuth）に対してリソースサーバ（HTTPサービス）へのアクセス権を要求
- 認可サーバーはリソースオーナー（サードパーティアプリの持ち主）に対してリソースサーバへのアクセス権を要求
- リソースオーナーは認可サーバに対してリソースサーバへのアクセス権を許可
- 認可サーバーはクライアントに対してアクセストークンを発行
- クライアントはアクセストークンによりリソースサーバにアクセス
アクセストークンとリフレッシュトークンの関係
アクセストークンは、クライアントからリソースサーバへアクセスしてもよいですよと、リソースオーナーが許可を出した発行書のようなもの。
よって流出するとリソースサーバが操作されてしまうため有効期限が付される。
この時、有効期限が切れるたびに毎回リソースオーナーが再度許可を出すのはUX上宜しくないので、この許可を自動化しアクセストークンの再発行に使うものがリフレッシュトークンとなる。
リフレッシュトークンにも有効期限があり、アクセストークンよりも長い。
アクセストークンが流出しても有効期限が短いため、被害は限定される。
リフレッシュトークンが流出しても認可サーバ側で検知して新規のアクセストークンを発行させないようにすれば、被害は限定される。
SSL/TLS
通信への攻撃（盗聴、改ざん、なりすまし、否認）からデータを保護する仕組み。例えばHTTPからHTTPSにするとか。
SSLの発展系がTLSとなるため、TLSで整理すると・・・
TLSの機能
| 機能 | 目的 | 概要 |
|---|---|---|
| 暗号化 | 盗聴対策 | 2者間でルールを決め、2者間でしか読めないデータを作る |
| MAC | 改ざん対策 | データとMAC値を送り、データをMAC関数で計算した値とMAC値の一致をもって改ざんされていないとみなす |
| 電子署名 | なりすまし、否認対策 | 送信元の秘密鍵で暗号化したデータを送り、送信元の公開鍵で複合した結果をもって送信元を特定する |
TLSの適用
TLSが様々なプロトコルに適用され通信データを保護する
- HTTP→HTTPS
- FTP→FTPS
- SMTP→SMTPS
証明書
電子署名などで使う公開鍵について、不正な公開鍵を使われるとTLSの機能の意味がなくなる。よって、公開鍵が正当な被証明者のものであることを証明するために認証局などから発行されるものが（電子）証明書。公開鍵、被証明者の署名、被証明者の情報を含む。
その他
- HTTPSは暗号化する分HTTPに比べ通信が遅くなるため、必要なところのみHTTPSとするのが良い設計。例えば、AWSでIGW→ALB→EC2への通信経路の場合は、IGW→ALBのみHTTPSとし、ALB→EC2はセキュリティグループでアクセス制限をかけているためHTTPとするのが良い
- 0.0.0.0は全てのIPアドレスの範囲を表す
参考文献
まとめてみましたが図などないと流れがわかりずらいですね・・・。
これらの文献を参考にさせていただきましたので、詳細などはご参照ください。