Skip to main content
OAuth 2.0認可フレームワークは、複数の異なるフロー (またはグラント) をサポートしています。とは、を取得する方法です。どのフローがユースケースに適しているかは、主にアプリケーションの種類によって決まりますが、クライアントの信頼レベルや、ユーザーにどのような体験を提供したいかといった、ほかの要素も関係します。

​
OAuth 2.0の用語

  • : 保護されたリソースへのアクセスを許可できるエンティティ。通常はエンドユーザーを指します。
  • クライアント: リソース所有者に代わって、保護されたリソースへのアクセスを要求するアプリケーション。
  • : 保護されたリソースをホストするサーバー。アクセス先の API です。
  • : リソース所有者を認証し、適切な認可を得たうえでアクセストークンを発行するサーバー。この場合は Auth0 です。
  • ユーザーエージェント: リソース所有者がクライアントとやり取りするために使用するエージェント (たとえば、ブラウザーやネイティブアプリケーション) 。

​
クライアントはリソース所有者ですか？

最初の判断ポイントは、リソースへのアクセスを必要とする主体がマシンかどうかです。マシン間認可の場合、クライアントはリソース所有者でもあるため、エンドユーザーによる認可は必要ありません。たとえば、API を使用して情報をデータベースに取り込む cron ジョブがこれに当たります。この例では、cron ジョブは と を保持し、それらを使って認可サーバーからアクセストークンを取得するため、クライアントであると同時にリソース所有者でもあります。 このケースが要件に合う場合は、このフローの仕組みと実装方法について クライアント認証情報フロー を参照してください。

​
クライアントはサーバー上で動作するウェブアプリですか？

クライアントがサーバー上で動作する従来型のウェブアプリである場合は、認可コードフローを使用します。このフローを使うと、クライアントはアクセストークンと、必要に応じてを取得できます。アクセストークンは、ユーザーのウェブブラウザーを経由せず、クライアントをホストしているウェブサーバーに直接渡されるため、漏えいのリスクが低く、最も安全な選択肢とされています。 このケースが要件に合っている場合は、このフローの仕組みと実装方法について、認可コードフローを参照してください。

​
ユーザーの資格情報を託せるほど、クライアントは完全に信頼できますか？

この判断ポイントによっては、Resource Owner Password Credentials Grant を選ぶことになります。このフローでは通常、インタラクティブなフォームを使って、エンドユーザーに資格情報 (識別子/パスワード) を入力してもらいます。この情報はバックエンドに送信され、さらにそこから Auth0 に送られます。そのため、クライアントがこの情報を安心して任せられるほど信頼できることが不可欠です。 このグラントは、認可コードフロー のようなリダイレクトベースのフローが利用できない場合にのみ使用すべきです。これに当てはまる場合は、このフローの仕組みと実装方法について Resource Owner Password Flow を参照してください。

​
クライアントはシングルページアプリですか？

クライアントがシングルページアプリ (SPA) (JavaScript のようなスクリプト言語を使ってブラウザー上で動作するアプリケーション) の場合、グラントには 2 つの選択肢があります。Proof Key for Code Exchange (PKCE) を使用した認可コードフローと、Form Post を使用する Implicit Flow です。ほとんどのケースでは、アクセストークンがクライアント側に公開されず、このフローではリフレッシュトークンも返せるため、PKCE を使用した認可コードフローの利用をお勧めします。 このフローの仕組みや実装方法について詳しくは、Authorization Code Flow with Proof Key for Code Exchange (PKCE)を参照してください。Auth0 Single-Page App SDK では、SPA で PKCE を使用した認可コードフローを実装するための高水準 API が提供されています。 SPA でアクセストークンが不要な場合は、Form Post を使用する Implicit Flow を利用できます。このフローの仕組みや実装方法について詳しくは、Implicit Flow with Form Postを参照してください。

​
クライアントはネイティブ／モバイルアプリですか？

アプリケーションがネイティブアプリの場合は、Proof Key for Code Exchange (PKCE) を使用する認可コードフローを使用してください。 このフローの仕組みや実装方法について詳しくは、Proof Key for Code Exchange (PKCE) を使用する認可コードフローを参照してください。

​
異なるリソースサーバーと通信する必要があるアプリケーションがある場合

1 つのアプリケーションで異なるリソースサーバー向けのアクセストークンが必要な場合は、/authorize への呼び出しを複数回行う必要があります (つまり、同じまたは異なる を複数回実行する必要があります) 。各認可では audience に異なる値を使用するため、フローの最後にそれぞれ異なるアクセストークンが生成されます。詳しくは、OAuth 2.0: Audience Information Specification を参照してください。

​
アプリケーションを実装する前にエンドポイントを試すことはできますか？

もちろんです。Authentication API Debugger Extension を利用できます。各 /grant エンドポイントの詳しい手順は、Authentication API Reference を参照してください。
  • Authorize エンドポイントについては、Authorize Application を開き、試したいグラントの「Test this endpoint」段落を読んでください。
  • については、Get Token を開き、試したいグラントの「Test this endpoint」セクションを読んでください。

​
クライアントアプリケーションは、ブラウザーを使った操作なしでユーザーに認証を求める必要がありますか？

クライアント主導のバックチャネル認証は現在、早期アクセスで提供されています。CIBA を有効にするには、担当の Technical Account Manager にお問い合わせください。
クライアント主導のバックチャネル認証 (CIBA) は、OpenID Connect とは異なる認証フローを実装するための Foundation の標準です。CIBA が標準の OpenID Connect フローと異なる点は、次のとおりです。
  • クライアントアプリケーションが、エンドユーザーに代わって認証プロセスを開始します。
  • ユーザー操作にブラウザーは必要ありません。
  • クライアントアプリケーションと OpenID プロバイダーの間で直接通信が行われます。
CIBA は、ユーザーがクライアントアプリケーションを信頼できない場合、クライアントアプリケーションにブラウザーがない場合、またはユーザーが認証を必要とするアプリケーションをその場で操作していない場合に役立ちます。CIBA フローを利用できる例をいくつか紹介します。
  • 小売店の販売端末でのユーザーチェックイン: クリック＆コレクトのシナリオでは、ユーザーは公共のキオスク端末で認証し、本人がその場にいることを確認できます。
  • コールセンターや窓口での認証: コールセンターの担当者は、通常はスマートフォン上のカスタムモバイルアプリを使って、電話をかけてきたユーザーを認証するための認証フローを開始できます。
  • 入力機能のないデバイスでの認証: たとえば、スマートスピーカー (または他の接続デバイス) は、通常はスマートフォン上のカスタムモバイルアプリを使って、バックエンドサービス経由でユーザーに認証を求めることができます。
CIBA では 2 種類のデバイスを定義しています。
  • Consumption device: ユーザーがサービスを利用するためのデバイスです。
  • Authentication device: ユーザーが認証を行い、同意を与えるデバイスです。
詳しくは、Client-Initiated Backchannel Authentication Flow をご覧ください。