認可コードフローを使用してログインを追加する

認可コードフローを使用して、従来型の Web アプリケーションにログイン機能を追加する方法を学びます。

認可コードフローを使用すると、通常の Web アプリケーションにログインを追加できます。フローの仕組みと、これを使用すべき理由については、Authorization Code Flow をご覧ください。通常の Web アプリから API を呼び出す方法については、Call Your API Using the Authorization Code Flow をご覧ください。

認可コードフローを実装するために、Auth0 では次のリソースを提供しています。

• Regular Web App Quickstarts: フローを実装する最も簡単な方法です。
• Authentication API: 独自のソリューションを構築したい場合は、このまま読み進めて API を直接呼び出す方法をご確認ください。

ログインに成功すると、アプリケーションはユーザーの ID トークン と アクセストークン を利用できるようになります。ID トークンには基本的なユーザープロファイル情報が含まれており、アクセストークンは Auth0 の /userinfo エンドポイントまたは独自の保護された API の呼び出しに使用できます。ID トークンの詳細については、ID Tokens をご覧ください。アクセストークンの詳細については、Access Tokens をご覧ください。

ユーザーの認可をリクエストし、authorization_code を付けてアプリにリダイレクトします。次に、そのコードをトークンと交換します。

​

事前準備

Auth0 にアプリケーションを登録します。詳しくは、従来型Webアプリケーションを登録するをご覧ください。

• Application Type で Regular Web App を選択します。
• Allowed Callback URL に {https://yourApp/callback} を追加します。
• アプリケーションの グラントタイプ に 認可コード が含まれていることを確認します。詳しくは、グラントタイプを更新するをご覧ください。

​

ユーザーを認可する

フローを開始するには、ユーザーの認可を得る必要があります。この手順には、次のプロセスのうち1つ以上が含まれる場合があります。

• ユーザーを認証する。
• 認証を行うために、ユーザーをIDプロバイダーにリダイレクトする。
• 以前に同意を得ていない場合は、要求された権限レベルに対するユーザーの同意を取得する。

ユーザーを認可するには、アプリからユーザーを認可URLに送信する必要があります。

​

認可 URL の例

​

パラメータ

パラメータ名	説明
response_type	Auth0 が返す資格情報の種類 (code または token) を示します。このフローでは、値は code である必要があります。
client_id	アプリケーションの Client ID です。この値は アプリケーション設定 で確認できます。
redirect_uri	ユーザーが認可すると、Auth0 がブラウザーをリダイレクトする先の URL です。認可コードは URL パラメータ code で受け取れます。この URL は、アプリケーション設定 で有効な callback URL として指定する必要があります。 警告: OAuth 2.0 Specification に従い、Auth0 はハッシュ以降の内容をすべて削除し、フラグメントは 一切 処理しません。
scope	認可をリクエストする scopes を指定します。これにより、返されるクレーム (またはユーザー属性) が決まります。複数指定する場合はスペースで区切る必要があります。レスポンスで ID トークンを取得するには、少なくとも openid の scope を指定する必要があります。ユーザーの完全なプロファイルを返したい場合は、openid profile をリクエストできます。email など、ユーザーに関する standard OpenID Connect (OIDC) scopes や、namespaced format に準拠した custom claims をリクエストできます。リフレッシュトークン を取得するには offline_access を含めます (アプリケーション設定 で オフラインアクセスの許可 フィールドが有効になっていることを確認してください) 。
state	(推奨) アプリが最初の request に追加する、不透明な任意の英数字文字列です。Auth0 はアプリケーションにリダイレクトする際、この値を含めます。この値を使ってクロスサイトリクエストフォージェリ (CSRF) 攻撃を防ぐ方法については、Mitigate CSRF Attacks With State Parameters を参照してください。
connection	(任意) ユーザーに特定の接続でのサインインを強制します。たとえば、github を渡すと、ユーザーは GitHub アカウントでログインするため直接 GitHub に移動します。指定しない場合、ユーザーには設定済みのすべての接続を含む Auth0 Lock 画面が表示されます。設定済みの接続の一覧は、アプリケーションの 接続 タブで確認できます。
organization	(任意) ユーザーの認証時に使用する organization の ID です。指定しない場合、アプリケーションで Display Organization Prompt が設定されていれば、ユーザーは認証時に organization名 を入力できます。
invitation	(任意) organization 招待のチケット ID です。Organizations にメンバーを招待する 場合、ユーザーが招待を承諾するときに、アプリケーションは invitation と organization のキーと値のペアを転送して、招待の承諾を処理する必要があります。
login_hint	(任意) Auth0 へリダイレクトする際に、ログインまたはサインアップページのユーザー名/メール フィールドを自動入力します。Universal Login エクスペリエンスでサポートされています。

例として、アプリにログインを追加する際の認可 URL 用 HTML スニペットは次のようになります。

​

レスポンス

問題なく進めば、HTTP 302レスポンスが返されます。認可コードはURLの末尾に含まれます。

HTTP/1.1 302 Found
Location: {https://yourApp/callback}?code={authorizationCode}&state=xyzABC123

​

トークンをリクエストする

認可コードを取得したら、それをトークンと交換する必要があります。前のステップで取得した認可コード (code) を使って、トークンURL に POST します。

​

トークン URL にPOSTする例

​

パラメーター

パラメーター名	説明
grant_type	authorization_code に設定します。
code	このチュートリアルの前の手順で取得した authorization_code です。
client_id	アプリケーションの Client ID です。この値は アプリケーション設定 で確認できます。
client_secret	アプリケーションの Client Secret です。この値は アプリケーション設定 で確認できます。利用可能なアプリケーションの認証方法について詳しくは、Application Credentials を参照してください。
redirect_uri	アプリケーション設定で指定した有効な callback URL です。これは、このチュートリアルの前の手順で認可 URL に渡した redirect_uri と完全に一致している必要があります。なお、URL エンコードが必要です。

​

レスポンス

問題なく完了すると、access_token、refresh_token、id_token、token_type の値を含むペイロードを含む HTTP 200 レスポンスが返されます。

{
  "access_token": "eyJz93a...k4laUWw",
  "refresh_token": "GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type": "Bearer"
}

保存する前に、トークンを検証してください。方法については、ID トークンを検証する と アクセストークンを検証する を参照してください。

ID トークン には、デコードして抽出する必要があるユーザー情報が含まれています。

アクセストークン は、Auth0 Authentication API の /userinfo エンドポイント または別の API を呼び出すために使用されます。独自の API を呼び出す場合は、まず API 側で アクセストークンを検証する 必要があります。

リフレッシュトークン は、以前のアクセストークンまたは ID トークンの有効期限が切れた後に、新しいアクセストークンまたは ID トークンを取得するために使用されます。refresh_token は、offline_access スコープを含め、Auth0 Dashboard でその API に対して オフラインアクセスの許可 を有効にした場合にのみレスポンスに含まれます。

リフレッシュトークンを使用すると、実質的に無期限にユーザーの認証状態を維持できるため、安全に保管する必要があります。

​

ユースケース

​

基本的な認証リクエスト

この例では、ステップ1でユーザーを認証する際に送信できる、最も基本的なリクエストを示します。Auth0のログイン画面が表示され、ユーザーは設定済みの任意の接続を使ってサインインできます。

ここでトークンをリクエストすると、ID トークンには最も基本的なクレームが含まれます。ID トークンをデコードすると、以下のようになります。

{
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt9...",
  "exp": 1478112929,
  "iat": 1478076929
}

​

ユーザーの名前とプロフィール画像をリクエストする

通常のユーザー認証に加えて、この例では、名前やプロフィール画像などの追加のユーザー情報をリクエストする方法を紹介します。

ユーザーの名前とプロフィール画像をリクエストするには、ユーザーを認可する際に適切な scopes を追加する必要があります。

これで、トークンをリクエストすると、ID トークンに要求した name クレームと picture クレームが含まれるようになります。ID トークンをデコードすると、次のようになります。

{
  "name": "jerrie@...",
  "picture": "https://s.gravatar.com/avatar/6222081fd7dcea7dfb193788d138c457?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fje.png",
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt...",
  "exp": 1478113129,
  "iat": 1478077129
}

​

GitHub でユーザーをログインさせる

通常のユーザー認証に加えて、この例では GitHub などのソーシャルアイデンティティプロバイダーにユーザーを直接送る方法を紹介します。まず、Auth0 Dashboard > Authentication > Social で適切な接続を設定し、設定 タブから接続名を取得する必要があります。

ユーザーを GitHub のログイン画面に直接送るには、手順 1 でユーザーの認証を開始する際に、connection パラメーターを渡し、その値を接続名 (この場合は github) に設定する必要があります。

トークンをリクエストすると、ID トークンには GitHub から返されたユーザー固有の ID が sub クレームに含まれます。ID トークンをデコードすると、次のようになります。

{
  "name": "Jerrie Pelser",
  "nickname": "jerriep",
  "picture": "https://avatars.githubusercontent.com/u/1006420?v=3",
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "github|100...",
  "aud": "xvt...",
  "exp": 1478114742,
  "iat": 1478078742
}

​

詳しくはこちら

• OAuth 2.0 認可フレームワーク
• OpenID Connect プロトコル
• トークン
• 従来型Webアプリケーションを登録する
• グラントタイプを更新する