認証と認可

認証：アクセスしようとしている人が本当に本人かを確認する
- 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属性は送信元を指定する属性である。

参考

今さら聞けない暗号技術＆認証・認可
Basic認証、Digest認証、Bearer認証、OAuth認証方式について
クロスサイトスクリプティング(XSS)対策としてCookieのHttpOnly属性でどこまで安全になるのか