- Regular Web App Quickstarts: フローを実装する最も簡単な方法です。
- Authentication API: 独自のソリューションを構築したい場合は、このまま読み進めて API を直接呼び出す方法をご確認ください。
/userinfo エンドポイントまたは独自の保護された API の呼び出しに使用できます。ID トークンの詳細については、ID Tokens をご覧ください。アクセストークンの詳細については、Access Tokens をご覧ください。
ユーザーの認可をリクエストし、authorization_code を付けてアプリにリダイレクトします。次に、そのコードをトークンと交換します。
事前準備
Auth0 にアプリケーションを登録します。詳しくは、従来型Webアプリケーションを登録するをご覧ください。- Application Type で Regular Web App を選択します。
- Allowed Callback URL に
{https://yourApp/callback}を追加します。 - アプリケーションの グラントタイプ に 認可コード が含まれていることを確認します。詳しくは、グラントタイプを更新するをご覧ください。
ユーザーを認可する
フローを開始するには、ユーザーの認可を得る必要があります。この手順には、次のプロセスのうち1つ以上が含まれる場合があります。- ユーザーを認証する。
- 認証を行うために、ユーザーをにリダイレクトする。
- 以前に同意を得ていない場合は、要求された権限レベルに対するユーザーの同意を取得する。
認可 URL の例
パラメータ
例として、アプリにログインを追加する際の認可 URL 用 HTML スニペットは次のようになります。
レスポンス
問題なく進めば、HTTP 302レスポンスが返されます。認可コードはURLの末尾に含まれます。
トークンをリクエストする
認可コードを取得したら、それをトークンと交換する必要があります。前のステップで取得した認可コード (code) を使って、トークンURL に POST します。
トークン URL にPOSTする例
パラメーター
レスポンス
問題なく完了すると、access_token、refresh_token、id_token、token_type の値を含むペイロードを含む HTTP 200 レスポンスが返されます。
refresh_token は、offline_access スコープを含め、Auth0 Dashboard でその API に対して オフラインアクセスの許可 を有効にした場合にのみレスポンスに含まれます。
ユースケース
基本的な認証リクエスト
この例では、ステップ1でユーザーを認証する際に送信できる、最も基本的なリクエストを示します。Auth0のログイン画面が表示され、ユーザーは設定済みの任意の接続を使ってサインインできます。 ここでトークンをリクエストすると、ID トークンには最も基本的なクレームが含まれます。ID トークンをデコードすると、以下のようになります。ユーザーの名前とプロフィール画像をリクエストする
通常のユーザー認証に加えて、この例では、名前やプロフィール画像などの追加のユーザー情報をリクエストする方法を紹介します。 ユーザーの名前とプロフィール画像をリクエストするには、ユーザーを認可する際に適切な scopes を追加する必要があります。 これで、トークンをリクエストすると、ID トークンに要求したname クレームと picture クレームが含まれるようになります。ID トークンをデコードすると、次のようになります。
GitHub でユーザーをログインさせる
通常のユーザー認証に加えて、この例では GitHub などのソーシャルアイデンティティプロバイダーにユーザーを直接送る方法を紹介します。まず、Auth0 Dashboard > Authentication > Social で適切な接続を設定し、設定 タブから接続名を取得する必要があります。 ユーザーを GitHub のログイン画面に直接送るには、手順 1 でユーザーの認証を開始する際に、connection パラメーターを渡し、その値を接続名 (この場合は github) に設定する必要があります。
トークンをリクエストすると、ID トークンには GitHub から返されたユーザー固有の ID が sub クレームに含まれます。ID トークンをデコードすると、次のようになります。