MyMapUMLシーケンス図 - API認証
プロンプト
クライアント、APIゲートウェイ、認証サービス、データベースを含むREST API認証フローのUMLシーケンス図を作成してください
自分用に作り直す
フレームワークについて
ブラウザーとバックエンドをまたぐサインインを追跡する
このシーケンス例には、User、Browser、Backend API、OAuth Provider、DBの5つの参加者が含まれています。12個のメッセージはGoogleでのサインインから始まり、認証、同意、認証コードのコールバック、トークン交換、ユーザーレコードのアップサート、セッションCookie、ダッシュボードへのリダイレクトへと進みます。
サンプルでは、プロバイダーがアクセストークンとIDトークンの両方を返します。図が示すのは成功時のフローのみです。トークン検証、リクエスト相関チェック、PKCE、同意拒否、期限切れコード、データベース障害は示していません。コールバックには POST /auth/callback と明示されていますが、これはサンプルアプリケーション上の手順であり、実装に合わせて調整してください。
このシーケンスを使って、各リクエストを誰が開始し、ブラウザーがどの時点で処理をサーバーに引き渡すのかを明確にしましょう。設計仕様として扱う前に、検証手順や別の結果分岐を追加してください。プロトコルの詳細と、アプリケーション固有のセッション動作は明示しておくことが重要です。
含まれる内容
得られるもの
- ユーザー、ブラウザー、バックエンド、プロバイダー、データベースにまたがる5本のライフライン
- 成功するサインインを示す12個の順序付きメッセージ
- ユーザーレコードのアップサートに続く認証コード交換
- 最後に行われるセッションCookie設定とダッシュボードへのリダイレクト
UMLシーケンス図 - API認証
✦ Free preview · Sign in to use
よくある質問
よくある質問
ログインに失敗するシナリオも含まれていますか？
いいえ。12個のメッセージはすべて成功時のフローに属します。拒否された同意、無効または期限切れのコード、ユーザーレコードの書き込み失敗に対応する分岐も追加で指定してください。
プロバイダーがトークンを返した後はどうなりますか？
サンプルのバックエンドはユーザーレコードをアップサートし、ユーザーオブジェクトを受け取り、セッションCookieを設定します。トークンの検証やセッション保存の詳細は描画していません。
自分のアプリケーションでも POST /auth/callback は必要ですか？
そのラベルはあくまで例です。コールバックのメッセージを、プロバイダーの設定とバックエンドのルートに合わせてください。プロバイダーによるリダイレクトと、その後にブラウザーからバックエンドへ送られるリクエストを区別することが重要です。
UMLシーケンス図 - API認証
無料で開始。クレジットカード不要。