こんにちは！代表取締役 兼 AIサービス開発室の鈴木生雄です。
前回の記事では、バックエンドサービスSupabaseを紹介し、認証についてはSupabase Authが受け持っていることに触れました。今回はその認証を深掘りします。Shoelogの認証方式として採用した「Sign in with Apple」の紹介と、ログインボタンを押してから自分のデータが画面に表示されるまでの裏側で何が起きているのかを解説します。
Sign in with Appleとは
Sign in with Appleは、Apple Accountを用いてアプリへログインするための仕組みです。利用者はShoelog専用のパスワードを新たに作成する必要がなく、端末の設定に応じてFace ID、Touch IDまたはパスコードを用いて本人確認を行うことができます。
利用者から見ると、ログイン画面のボタンを押して、Face IDで顔認証すれば完了です。「またパスワードを考えて、また忘れるのか……」というあの憂鬱がありません。皆さんも、新しいサービスに登録するたびにパスワードを考えさせられて、うんざりした経験があるのではないでしょうか。
なぜ独自認証にしなかったのか
認証の実装方法として、メールアドレスとパスワードによる独自認証を作る選択肢もありました。前回紹介したとおり、Supabase Authはメールアドレス・パスワード認証にも対応しているので、技術的には可能です。
しかし、独自のメールアドレス・パスワード認証を実装する場合、パスワードの保存、再設定、漏えい対策、不正ログイン対策などを開発者自身が考慮する必要があります。パスワードというのは、持っているだけでリスクになる情報なのです。
今回はSign in with Appleを採用することで、本人確認とApple Accountの管理をAppleに任せ、Shoelogでは認証結果だけを利用する構成としました。認証画面の表示と本人確認はiOSによって行われるため、ShoelogがApple Accountのパスワードを取得することはありません。持たなければ、漏らしようがない。これが一番の安心材料です。
セキュリティのプロを多数抱えるAppleに任せられるところは任せて、自分はアプリ固有の開発に集中する。前回のBaaSの話と同じで、「作らない」という判断こそが、週末開発を成立させる鍵だったと思います。
認証の流れ：ボタンを押した後、何が起きているのか
Shoelogのログイン画面には、Appleが提供する標準のSign in with Appleボタンを配置しています。利用者がこのボタンを押すと、iOSがApple Accountの認証画面を表示します。ここから先、画面の裏側では次のような処理が流れています。
- Appleによる本人確認：Face ID、Touch IDまたはパスコードで、端末を操作している人物の本人確認が行われます
- Identity Tokenの受け取り：Appleによる認証が成功すると、iPhoneアプリは認証結果としてIdentity Tokenを受け取ります。Identity Tokenは、認証された利用者や発行元などの情報を含み、Appleによって電子署名されたトークンです
- Supabase Authへの送信と検証：Shoelogは、このIdentity TokenをSupabase Authへ送信します。Supabase Authは、Appleの署名とトークンの内容を検証したうえで対応する利用者を特定し、初回ログインの場合は新しい利用者として登録します
- セッションの発行：その後、Supabase AuthはShoelogがデータアクセスに使用するセッションを発行します
AppleとSupabase Authの役割分担
この構成のポイントは、AppleとSupabase Authが役割を分担していることです。
- Appleは、端末を操作している人物の本人確認を行う
- Supabase Authは、その認証結果をShoelogの利用者に関連付けてセッションを管理する
すなわち、Appleによる認証をSupabase Authのセッションへ変換する、二段階の構成となっています。
そして、セッションには利用者を証明するアクセストークンが含まれます。iPhoneアプリは、データの取得・更新や写真の保存の際に、このアクセストークンを添えてSupabaseへアクセスします。データベース側では、前回紹介したRow Level Securityによって、利用者本人のデータに対する処理だけを許可します。
前回の記事で「最終的なアクセス可否はデータベース側で確認する」という話をしましたが、その判定材料となる「今アクセスしているのは誰か」という情報は、今回の認証の流れによって供給されていたわけです。認証（今回）とアクセス制御（前回）が一本の線で繋がったところで、バックエンドの話は一区切りです。
次回予告
次回は、Shoelogのプレミアムプランを支える「アプリ内課金」を取り上げます。Appleが提供するIn-App Purchaseの仕組みと商品種別、無料プランとプレミアムプランの設計、そして購入処理の状態遷移について紹介する予定です。お楽しみに！