OpenID Connect - この場合、idトークンを保護されたリソースに送信する必要がありますか？

Question

私は、ネイティブアプリケーションがリクエストを行うために必要なWeb APIを持っていると言います。このAPIは、ネイティブアプリを介してこれらのリクエストを行っているユーザーを認証する必要があります。 OpenID ConnectはOAuthによる認証ではなく認証に関するものであるため、正しい選択と思われます。

ネイティブアプリは、ユーザーの資格情報をIDPに送信し、アクセストークン（認証用）とIDトークン（認証用）を戻します。 OIDCの理解から、アクセストークンはAPIに送信されますが、IDトークンはネイティブクライアントアプリケーションのみに送信されます。それはネイティブアプリではなく、ユーザーが誰かを気にするAPIなので、私にとって意味をなさない。

なぜ、idトークンも保護されたリソース（別名API）に渡されないのですか？ IDトークンをAPIに渡さないと、アクセストークンが安全で、ユーザーの認証に使用できることを保証するものは何ですか？それ以外の場合は、OAuthをOAuth経由で使用する利点が失われているように見えます。

Answer 1

OIDC仕様は、IDトークンが常にクライアント（ネイティブアプリ）用であり、アクセストークンがリソース（API）用であるように設計されています。 IDトークンは常にJWTトークンですが、アクセストークンは異なるタイプにすることができます。

アクセストークンの目的は、認証するのではなく、承認することです（委任された承認）。なんらかの理由で、リソースサーバがユーザについて知りたい場合、ユーザ情報エンドポイントを呼び出すことができます。

セキュリティ/トークンの交換の有効性は、いくつかの方法で確認することができます。認証サーバは/その秘密鍵およびリソースとアクセストークンに署名し暗号化する公開鍵/秘密鍵モデルと暗号化/署名を使用して

• サーバは、公開鍵で復号化/検証を行う。 AUD、発行されたアクセストークンの検証でAZPヘルプのような主張を検証するためにトークンイントロスペクションのエンドポイントを使用して

• 、トークンなどの妥当性...

他の属性。

一部OIDCプロバイダは、APIのにアクセスするためにID_Tokensを使用する - これは、これらのシナリオについての説明を詳しく説明してい

このarticle OIDC仕様

によって提案されたモデルに異なっています。