概要 セッション認証とトークン認証について整理する。下記サイトで詳しく解説されていたので、自分はあくまで学びをアウトプットする目的として本記事を作成する。詳しく学びたい人は、こちらで確認してほしい。 早速だがセッション認証とトークン認証について、一言で言うと、セッション認証はサーバー側主体の認証方法であり、トークン認証はブラウザ側主体の認証方法である。 セッション認証 セッション認証は、ユーザがログイン成功した際に、ユーザ情報と紐付けたセッションIDを返す。ユーザはこのセッションIDをブラウザ上でクッキーとして保存して、サーバー側へリクエストを送る。具体的な流れを下記に示す。 ユーザがログイン認証を経て、サーバがユーザ情報と紐づけたセッションIDを発行する。 発行されたセッションIDをユーザのブラウザが受け取り、クッキーとして保存する。 クッキーとして保存されたセッションIDを用いて、ユー

Web アプリケーションを開発していて、別ドメインのログイン状態を取得する際に CORS の仕組みについて勉強することができたので、設定ポイントをまとめておきます。 CORS とは Cross-Origin Resource Sharing の頭文字をとった略語です。 通常、ブラウザでは異なるサイトへのリソースへのアクセスに制限をかけて、CSRF などの攻撃を防いでいます。 CORS とは、この制限に対し、適切な設定を行うことで異なるサイトのリソースを共有できるようにするものです。 オリジンとは ブラウザは、同じサイトか異なるサイトかについて、オリジン (Origin) という単位で区別します。 同一スキーム、同一ホストおよび同一ポートのものが同一オリジン (Same-Origin) となります。 同じホストでも、スキーム (http/https) やポートが違っていれば異なるオリジンとな

Cookie OAuth2 OIDC（JWT）にみる認証の分散化 近年、HTML5が登場し、ブラウザがローカルコンピューターを操る自由度が増した結果、HTMLが複数のクラウドバックエンドAPI呼び出しの中心として役割を変化させてきました。 ここで、認証サービスに関してもクラウドバックエンドの機能のひとつとして、バックエンドAPIとして分離される事が可能となったので、今までのトレンドからこの傾向を解明していきます。 ※尚、本稿はSAMLには触れていません。 １．Cookieによるクライアント・サーバー型認証 旧来のクッキーによる認証は、セッションIDをクッキーに持たせるというもので、アプリケーションサーバーがその機能を包含しています。 但しログインユーザーの権限等の仕様はクッキー自体が持っていない為、アプリケーション側でDBにテーブルを作るなどしてアクセス権限の操作をする必要がありました。