はじめに

　Webサービス/Webアプリケーションを作成する際のフロントエンド開発の選択肢として、Single Page Application（以降、SPA）を候補に挙げることが多くなってきました。これはReact、Vue、Angularのようなフロントエンドのライブラリー・フレームワークの後押しによって、SPAの開発が随分と楽になったおかげです。

　多くのWebサービスやアプリは、ユーザー認証をどこかのタイミングで組み込む必要があります。しかし、多くのサービスではユーザー認証はサービスロジックではないので、そこまで労力をかけたくない部分でもあります。

　クラウド認証プラットフォームの「Auth0（オースゼロ）」は、そのような開発者の悩みを解決してくれるIDaaS（Identity-as-a-Service）です。アプリケーションへの簡単な組み込みや、強力なカスタマイズ機能、多言語対応など、手間のかかる認証処理の実装を解決してくれます。

　本書では認証の基礎技術から、OAuthやOpenID Connectの解説をふまえ、Auth0をSPAに組み込む方法を学ぶことができます。

　認証技術は、セキュリティの観点から表に情報が公開されにくい分野です。全てのサービスの開発現場においてセキュリティのプロフェッショナルが存在し、認証を自前実装する知識・体力・期間があるのであれば、このようなサービスは不要なのかもしれませんが、決してそうではないのが現実です。

　サービスの性質やフェーズによっては、非常に強力なツールとなるのがAuth0です。開発の際に選択肢のひとつとして考えてみてください。

この本で学べること

　本書では次のようなことを学ぶことができます。

　・認証の基礎技術

　・OAuth・OpenID Connect・JWTの仕組み

　・Auth0の概要、組み込み方、使い方、カスタマイズ

　・Nuxt.jsの簡単な使い方

　・JWTの発行からAPIアクセスまで一連の流れの実装

　これらにより、Auth0をSPAに組み込んで認証を行い、セキュアなAPIへのリクエストを体験できます。フロントエンドは、SPAを手早く作るためにVue.jsのフレームワークであるNuxt.jsを使い、サーバーサイドは、Rails API Modeを使ってシンプルに構築します。

　きれいな実装よりも、短時間でひととおり動かして理解することを目的として進めていきますので、ハンズオンのように読み進めてください。

前提としているスキル

　初心者向けの内容ですが、Ruby on RailsとVue.jsの軽めの知識を前提としています。

　・Vue.jsを触ったことがある

　・Rails Tutorialを終わらせた程度のサーバーサイドについての知識がある

免責事項

　本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

　できる限り正確を期すよう執筆しましたが、その保証はありません。本書の内容に基づく行動に対して、著者、発行者は一切の責任を負いかねます。OSSをベースにした開発ですので、どのOSSが破壊的変更を伴ったバージョンアップを行うかは、読めません。そのため、いくつかのライブラリが本書で紹介したとおりに動作しなくなっているかもしれません。ご了承ください。

表記関係について

　本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。

リポジトリとサポートについて

　本書に掲載されたコードと正誤表などの情報は、次のURLで公開しています。

　https://github.com/impressrd/support-auth0spa

底本について

　本書籍は、技術系同人誌即売会「技術書典4」で頒布されたものを底本としています

第1章　ウェブアプリケーションと認証

本書は主にトークンベースの認証（トークン認証）を扱う本ですが、この章ではトークン認証の詳しい解説に入る前に、いくつかのウェブアプリケーションのアーキテクチャーについて紹介し、伝統的なクッキーベースの認証（クッキー認証）とトークン認証との関連について解説します。

1.1　モノリシックなアプリケーション

　近年ではマイクロサービスやサーバーレスアーキテクチャーが話題になっていますが、まずは伝統的で単純な構成のウェブアプリケーションを考えてみましょう。

　要件にもよりますが、ウェブアプリケーションを開発する手段として、まずはフルスタックなフレームワークの利用を検討するのではないでしょうか。フルスタックなウェブフレームワークは、単体である程度の機能をもつアプリケーションを構築でき、そのエコシステムによって開発者の生産性を向上させます。この場合、単体でアプリケーションを構築するのでモノリシックなアプリケーションとも呼びます。言語別に有名なフレームワークでは、RubyならRuby on Rails。PHPならLaravel、CakePHP、CodeIgniterなど。PythonならDjangoでしょうか。

　筆者もRailsのエコシステムにどっぷり浸かっている人間の一人です。フルスタックウェブフレームワークは、フロントエンド開発のサポート、ORMにはじまるデータベース連携、ジョブ管理などさまざまな機能が付属していますが、一度ひとつのフレームワークで開発を進めてしまうと、フレームワークが推奨する道から外れた開発をすることが難しいという特徴もあります。この「フレームワークが推奨する開発方針」のことは、Railsなら「Railsway」とも呼ばれていますね。

1.2　モノリシックなアプリケーションとクッキー認証

　モノリシックなアプリケーションで「認証」というと、多くは古典的なクッキー認証を指します。場合によっては、セッションベースの認証・セッション認証・セッションクッキーなどとも呼ばれますが、本書ではこれらをクッキー認証と呼んで話を進めます。

　Rails以降のAPIサーバーを意識したアプリケーションも増えていますが、古典的と呼ばれながらも、クッキー認証はいまだに現役で使われています。フレームワークによってはクッキー認証の仕組みが組み込まれているものもあれば、RailsのようにDeviseやSorceryと呼ばれる外部ライブラリで実現することもあります。

　どちらにせよ、フレームワークを使用しているのに認証周りの仕組みを自作するケースは極めて少ないでしょう。場合によっては自分自身でセキュリティホールを作ってしまう可能性を考えると、先人によってバグが踏み抜かれ磨かれたソフトウェアを使うことは、開発者に一定の安心感をもたらします。

　クッキー認証では、ユーザーのログイン状態をセッションとしてサーバー側で保管し、ブラウザのクッキーにセッションのIDを保存します。手順としては、1. ユーザーはログインのために、ブラウザからユーザーIDとパスワードを送信します。2. サーバーは送られてきたユーザーIDとパスワードを検証し、セッションに保存します。3. サーバーは保存したセッションIDをブラウザに返します。4. ブラウザはセッションIDをクッキーに保存します。5. 次回リクエスト以降から、セッションIDを含めてリクエストを行います。6. サーバーはリクエストに含まれたセッションID元にログイン状態のユーザーを特定します。ここで特定に失敗した場合は、ログインページにリダイレクトするなどして、再度ログインを促します。ユーザーがログアウトすると、クライアントとサーバーサイド両方のセッションが破棄されます。

　クッキー認証では、システムがユーザーのログイン状態を保持するため、ステートフルな設計になります。クッキー認証はシンプルですが、サーバーを複数台設置する場合は、それぞれのサーバー間でクライアント状態の同期が必要になるため、スケールアウトが難しい認証方法でもあります。

目次