web-dev-qa-db-ja.com

OIDC / OAuth2 id_tokenおよびクライアントアプリケーションでの使用

最近、アプリケーションをログインに外部プロバイダーを使用するように移行しました。これにより、アプリケーションで認証を処理したり、ユーザーの資格情報を保存したりする必要がなくなります。このため、私はOAuth2でOpenID Connect(OIDC)を使用しているため、認証フローは非常に標準的です(私のアプリにアクセス-> OIDCプロバイダーの(OIDCP)ログインページにリダイレクト->ログイン/許可アクセス->コードでアプリに戻る->アクセス/ IDトークンのコードを交換します)。しかし、私が正しく理解したかどうかはわかりませんが、いくつかの概念があります。

  1. 外部プロバイダーを認証(承認ではなく)にのみ使用していますが、2つのトークン(accessおよびidトークン)を受け取ります。 accessトークンは、OIDCPが提供するユーザー情報エンドポイントを介してユーザーに関する詳細情報を取得するためにのみ使用し、id_tokenの情報が次の場合にのみ使用することを正しく理解していますか?十分ではない?

  2. id_tokenを使用してエンドポイントを呼び出すか、それともアプリの一部の「署名済みペイロード」のみを使用して、アプリがユーザーに関する情報を取得できるようにしますか(つまり、リクエストを行う必要がありますAuthorization: Bearer <id_token> ?)

  3. id_tokenは1回だけ使用することを意図していますか。つまり、OIDCPのトークンエンドポイントから受信し、IDを抽出し(つまり、subを読み取り)、アプリケーションでユーザーのセッションを作成して、忘れますid_tokenについてまたは、ユーザーにこのトークンを渡して、ユーザーが自分のIDを知る必要があるアプリのエンドポイントを呼び出すたびに、このトークンを渡すようにする必要がありますか?

  4. 前の質問に対する答えが、このユーザーのセッションを作成してid_tokenを忘れる必要があるというものである場合、意味的に言えば、セッションがexpid_tokenの時間を尊重する必要があります?言い換えると、expの時間はid_token自体の有効期限のみに関係するのですか、それとも、このユーザーのセッションをこれより長く設定しないようにクライアントアプリが一般的に推奨するものですか?値?

ありがとう

2
leopik
  1. アクセストークンは、外部プロバイダーが承認サーバーの役割を持つリソースへのアクセスを許可するために使用されます。この場合、UserInfoエンドポイントは、外部プロバイダーによってアクセスが保護されるリソースです。

  2. いいえ。ベアラートークンとしてIDトークンを使用してリクエストを行うことはありません。しかし、OpenIDConnectプロトコルで定義されたリクエストでは、id_tokenを「ヒント」として使用できます。この例は、id_token_hintを送信して、どの認証済み(または過去の認証済み)セッションがすでに発行されたか(有効または無効)を示す認証リクエストです。

  3. Id_tokenは、それを要求したクライアント(Relying Partyと呼ばれます)に対してのみ発行されます。このトークンを他の当事者(クライアントまたはリソース)に送信しないでください。私の経験から、存続期間の短いIDトークンがあります(5分)。これを検証し、ユーザーが正しいことを確認します(「sub」を抽出してトークンを検証します)。ユーザーの資格情報を取得したい場合は、id_tokenからそれらを抽出することもできます(IDプロバイダーに含まれている場合のみ)。ただし、多くの場合、UserInfoエンドポイントを使用して、アクセストークンでそれらを要求します。その後、すべてのユーザー情報を使用してアプリケーションセッションを作成します。重要なのは、前に説明したように、id_tokenをストレージ(アプリケーションセッションなど)に保管して使用することです。

  4. いいえ。id_tokenの「Exp」を尊重していません。 3の私の答えを見てください。私のIDトークンは5分間有効ですが、セッションははるかに長くなります。これは「単なる」推奨事項だと思います。

それがあなたを助けることを願っています。

1
Bartosz Rosa