web-dev-qa-db-ja.com

OAuth2 / OpenID Connectでロールベースの認証を行う方法は?

私は認証/承認にOAuth2を使用しようとしていますが、周りをよく読んだ後、混乱しています...私はOAuthとOpenIDConnectが相互にどのように関係し、どのように正確に私はそれらを認証に使用できます。

これまでに理解したことから

  • OpenID Connect は認証に最適、OAuthは認証に最適
  • OAuth2 承認はスコープを通じて行われます
  • スコープとは、リソースサーバーで検証された、ユーザーがクライアントに付与した権限です

  • openID Connect id_tokenは、主にクライアントアプリケーション用であり、ユーザー情報を提供するためのものであり、リソースサーバーがユーザーを検証する方法としてではありません

これが私のユースケースです

  • 私たちが作成した完全にステートレスなWebサービスのセットにSSOを提供する必要があります
  • OAuthはresource_owner付与に制限されています
  • IDサーバーは私たちの側で提供され、LDAPサーバーに接続されています
  • 信頼できるアプリのみをサービスプロバイダーとして登録できます

そして私が何をしているかしようとしている、それは私を驚かせます

  • 特定のWebサービスAPIにアクセスできるのは許可されたユーザーのみです

したがって、リソースサーバーで、外部エンティティによってユーザーに与えられたアクセス許可を確認する方法が必要です。どちらがOAuthの認証に使用することを禁じていると思いますか?

OAuth/OpenID接続でこれを実現する方法がわからない場合や、ユースケースに適合している場合でもわかりません。

  1. OAuth2スコープで機能するように役割ベースのアクセスを作成できますか?
  2. id_tokenをリソースサーバーに渡して、ユーザーのロールを含むクレームで(そしてaccess_tokenを完全に破棄して)もいいですか?したがって、id_tokenは認証と承認の両方に使用されます。 id_tokenが署名されており、ハッシュが含まれているとすれば、それで問題ありませんよね?
  3. OpenIDConnectで認証するには、id_tokenの存在を確認し、access_tokenをすべて廃棄して、独自のロールベースの承認システムを開発する必要がありますか?

テキストの壁についてお詫びします。ここでOAuth/OpenID Connectのスコープを誤解しているかどうかはわかりません。私は間違った仮定をしていますか?

ありがとうございました。

19
lv.

ロールの概念は、OpenID Connect(Oauth2)のアクセストークンで使用できます。

スコープは、アクセストークンに含める必要があるユーザーに関するクレームの要求であると考えてください。アクセスをリクエストするAPIは、(たとえば)「従業員」の役割が必要であることを知っており、「scope=openid roles "リクエストのクエリパラメータ。

認証サーバー(AS)は、ユーザーに関する役割情報(LDAPディレクトリなど)にアクセスできます。その後、ユーザーのロールを検索し、それらをアクセストークンの「ロール」クレームに含めることができます。

また、ロール自体(scope=openid employee)。その場合、ユーザーがそのグループのメンバーであれば、ASはそれを含めることができます。必要な役割に関する詳細な知識が必要なため、これは少しスケーラブルではありませんが、トークン内のPIIの量が減り、そのサイズが小さくなります。また、ユーザーが指定されたグループのメンバーではない場合(つまり、スコープをトークンに含めることができない場合)、ASはOAuth2に従ってこれをAPIに通知する必要があります。

役割の使用はかなり一般的で、いくつかの例は次の場所にあります。

質問2)と3)に関しては、これを行わないでください:)

4
Geir Emblemsvag