認証と認可
- 認証：アクセスしようとしている人が本当に本人かを確認する
- ex. Basic認証、OpenID Connect
- 認可：（認証された）ユーザーが、どの情報や機能にアクセスできるかを決定する
- ex. OAuth 2.0
認可・認証方式の比較
Basic認証
ユーザー名とパスワードで認証を行う方式
Authorizationヘッダに Authorization: Basic <BASE64エンコードしたユーザ名:パスワード>をセットしてRequestを送る
※暗号化ではないため、HTTPSの利用が必須
※ログアウトの仕組みはない
Digest認証
ユーザー名とパスワードで認証を行う方式
サーバーで生成したランダムな文字列と組み合わせてハッシュ化することで、Basic認証よりセキュリティを強化している
※ログアウトの仕組みはない
Bearer認証
クライアントは事前に入手したアクセストークンをAuthorizationヘッダにセットして、リクエストを送信する
アクセストークンは主にOAuthで取得することが多い（Bearer認証はOAuthの規格の一部）
アクセストークンが盗まれると攻撃されるので、HTTPSの利用が必須
アクセストークンはフロントエンドで保管（CookieにHttpOnlyおよびSecureな値として保存するのが良い）し、HTTPヘッダーやメッセージボディで渡す
OAuth
クライアントが、アプリケーションへのログインなどでリソースオーナーの同意を得ると、認証サーバーは期限付きのアクセストークンを生成し、クライアントに送信する。
なお、この認可フローにはいくつかの種類が存在するが、一般的には、認可コードと交換でアクセストークンを取得するAuthorization Code Grantが用いられる。
クライアントとWebサーバー間は上記のBearer認証などを用いる
画像は今さら聞けない暗号技術＆認証・認可より
OpenID Connect
OAuth 2.0を拡張したプロトコルで、認証結果を含むアイデンティティ情報をIDトークンと呼ばれるJSON Web Token（JWT）に入れて受け渡す
画像は今さら聞けない暗号技術＆認証・認可より
IP制限
特定のIPアドレスまたはIPアドレス範囲からのみアクセスを許可する方法
なお、IPスプーフィング（IPアドレスのなりすまし）や内部からの攻撃を防ぐことは難しい
その他の用語
SSO（シングルサインオン）：1度のユーザー認証で複数のシステムの利用が可能になる仕組み。SSOを実現するプロトコルとして、OpenID ConnectやSAMLが存在する
フェデレーション認証：シングルサインオンを実現する方式の一つ。複数の組織やサービス間でユーザー認証を共有する仕組み。SAMLやOpenID Connectといったプロトコルにより実現される
SAML：SSOのフェデレーション認証方式を実現するプロトコルの一つ。OpenID Connectとは異なり、XML SAMLフォーマットを用いる
多要素認証：認証の3要素である「知識情報」、「所持情報」、「生体情報」のうち、2つ以上を組み合わせて認証すること
2段階認証：IDパスワードとは別に、第2の認証方法を設定する仕組み（要素は同じでも構わない）
認証情報の利用方法
認証/セッション情報として何を利用するか
OpenID Connectなどで、認証を行った後、ステートレスを実現するには2つの方法が考えられる
- サーバーサイドでSession IDを発行し、リクエストの際には、DBに問い合わせることでユーザ ID等を取得する
- OpenID Connectで得られたJWTをそのまま利用する、または認証後にサーバーサイドでJWTを発行する。ユーザ ID等はJWTに含まれる
JWTを利用するのはDBアクセスしなくて良いというメリットはあるが、サーバ側でのセッション無効化が難しく、Session IDのようなものを再発明する必要があるため、セッション管理という意味ではSession IDを利用することが望ましい
認証/セッション情報の保存場所
認証/セッション情報を保存する場所としては、CookieとLocal Storageの2つが考えられる。それぞれの主にセキュリティ面での比較は以下のようになる
| 項目 | Local Storage | Cookie |
|---|---|---|
| XSS | JavaScriptでアクセス可能なため脆弱 | HttpOnly属性をつけることで緩和策となる。ただし、Cookieを利用した秘密情報の盗み出しやなりすましによる攻撃は防止できない |
| CSRF | HTTPリクエストに自動的に付与されないので問題ない | SameSite属性でStrictまたはLax（POSTメソッドのリクエストのみを受け付ける処理の場合）を指定することで防止することが可能 |
すなわち、適切な設定を行ったCookieを利用した上で、XSSはあくまで緩和策であることに留意し、他の対策と組み合わせることが望ましい。
適切なCookieの設定
- Secure属性をつける
- 不適切なDomain指定を行わない（指定しなければCookieを発行したドメインのみ許可される。指定するとサブドメインまで許可されるので、指定しないのが安全）
- SameSite属性をStrictとする（POSTメソッドのリクエストのみを受け付ける処理の場合はLaxでも可）
- HttpOnly属性をつける
なお、Domain属性は送信先、SameSite属性は送信元を指定する属性である。