Authorization Code Flow を使用して Regular Web Application にログインを追加する

Authorization Code Flow を使用して、Regular Web Application にログインを追加する方法を説明します。

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

Authorization Code Flow を実装するために、Auth0 では次のリソースを提供しています。

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

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

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

​

前提条件

アプリを Auth0 に登録します。詳細については、Regular Web Applications の登録を参照してください。

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

​

ユーザーを認可する

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

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

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

​

認可 URL の例

​

パラメーター

Parameter Name	Description
response_type	Auth0 が返す認証情報の種類 (code または token) を示します。このフローでは、値は code である必要があります。
client_id	アプリケーションのクライアントIDです。この値は Application Settings で確認できます。
redirect_uri	ユーザーが認可を付与した後に、Auth0 がブラウザーをリダイレクトする URL です。認可コードは URL パラメーター code で取得できます。この URL は、Application Settings で有効な コールバック URL として指定する必要があります。 警告: OAuth 2.0 Specification に従い、Auth0 はハッシュ以降の内容をすべて削除し、フラグメントは 考慮しません。
scope	認可をリクエストする スコープ を指定します。これにより、どのクレーム (またはユーザー属性) を返すかが決まります。各値はスペース区切りで指定する必要があります。レスポンスで IDトークン を取得するには、少なくとも openid スコープを指定する必要があります。ユーザーの完全なユーザープロファイルを返したい場合は、openid profile をリクエストできます。email など、ユーザーに関する任意の standard OpenID Connect (OIDC) scopes や、namespaced format に準拠した カスタムクレーム をリクエストできます。Refresh Token を取得するには offline_access を含めてください (Application Settings で Allow Offline Access フィールドが有効になっていることを確認してください) 。
state	(推奨) アプリが最初のリクエストに追加する、不透明な任意の英数字文字列です。Auth0 はアプリケーションにリダイレクトする際にこの値を含めます。この値を使用して Cross-site Request Forgery (CSRF) 攻撃を防ぐ方法については、Mitigate CSRF Attacks With State Parameters を参照してください。
connection	(任意) ユーザーに特定の接続でサインインするよう強制します。たとえば、github を渡すと、ユーザーは GitHub アカウントでログインするために直接 GitHub にリダイレクトされます。指定しない場合、ユーザーには設定済みのすべての接続が表示された Auth0 Lock 画面が表示されます。設定済みの接続の一覧は、アプリケーションの Connections タブで確認できます。
organization	(任意) ユーザーの認証時に使用する組織の ID です。指定しない場合、アプリケーションで Display Organization Prompt が設定されていれば、ユーザーは認証時に組織名を入力できます。
invitation	(任意) 組織の招待のチケット ID です。組織にメンバーを招待する 場合、ユーザーが招待を承諾したときに、アプリケーションは invitation と organization のキーと値のペアを転送して、招待の承諾を処理する必要があります。
login_hint	(任意) Auth0 へリダイレクトする際に、ログインページまたはサインアップページの username/メールアドレス フィールドを事前入力します。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する例

​

パラメーター

Parameter Name	Description
grant_type	authorization_code に設定します。
code	このチュートリアルの前の手順で取得した authorization_code です。
client_id	アプリケーションのクライアントIDです。この値は Application Settings で確認できます。
client_secret	アプリケーションのクライアントシークレットです。この値は Application Settings で確認できます。使用可能なアプリケーションの認証方法の詳細については、Application Credentials を参照してください。
redirect_uri	Application Settings で設定した有効なコールバック 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 スコープを含め、Dashboard で API の Allow Offline Access を有効にした場合のみです。

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

​

ユースケース

​

基本的な認証リクエスト

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

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

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

​

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

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

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

これで、トークンをリクエストすると、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 などのソーシャル IDプロバイダーにユーザーを直接リダイレクトする方法を示します。まず、Auth0 Dashboard > Authentication > Social で適切な接続を設定し、Settings タブから接続名を取得する必要があります。

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

これで、トークンをリクエストすると、IDトークンには GitHub から返されたユーザーの一意の ID を含む sub claim が含まれます。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 プロトコル
• トークン
• Regular Web Application を登録する
• グラントタイプを更新する