Java >> Java チュートリアル >  >> Java

OAuth2、JWT、Open-ID Connect などのややこしいもの

免責事項

この投稿を始める前に、重要な免責事項から始めなければならないと感じた場合は、私の言おうとしている内容を信用しすぎないでください。 私がこれを言う理由は、私たちがセキュリティについて話し合っているからです。また、セキュリティについて話すとき、100% 正しいステートメント以外のことを言うと、何らかのリスクにさらされる可能性があります。 したがって、信頼できる情報源は公式の仕様である必要があること、およびこれは、このトピックを自分の頭の中で要約して初心者に紹介するために使用する概要にすぎないことを念頭に置いて、この記事を読んでください。

ミッション

OAuth2 はいつもわかりにくいので、この記事を書くことにしました .それについてもう少し知った今でも、その部分のいくつかは不可解であることがわかりました。
API をいじる必要があるときに、Google や Pinterest などのオンライン チュートリアルに従うことができたとしても、それはいつもある種のブードゥー教のように感じた 、これらすべてのコードと Bearer トークンを使用します。
標準的な OAuth2 アプローチの中から選択して、特定の手順について自分で決定できると彼らが言うたびに、私の心は盲目になりがちでした.

今後、OAuth2 チュートリアルをより自信を持って従うことができるように、いくつかのアイデアを修正できることを願っています。

OAuth2 とは

定義から始めましょう :

OAuth 2 は認可です フレームワーク アプリケーションを可能にする ユーザー アカウントへの制限付きアクセスを取得するため HTTP サービスで .

上記の文は合理的に理解できる 、しかし、選択した用語を特定すれば、物事を改善できます.

認証 名前の一部であり、認可であることを明らかにします (それは認証の可能性がありますが、そうではありません)。
フレームワーク フレームワークという用語はしばしば乱用されるため、見過ごされがちです。ただし、ここで押さえておくべき考えは、必ずしも最終製品または完全に定義されたものではないということです .ツールセットです。その上に何かを構築するために使用できるアイデア、アプローチ、明確に定義された相互作用のコレクションです!
アプリケーションを可能にします 制限付きアクセスを取得する .ここで重要なのは、人間ではなくアプリケーションを有効にすることです .
ユーザー アカウントへのアクセス制限 はおそらく、OAuth2 が何であるかを覚えて説明するのに役立つ定義の重要な部分です:
主な目的は、ユーザーが委任できるようにすることです。 ユーザー所有のリソースへのアクセス。アプリケーションへの委任。

OAuth2 は委任に関するものです。

これは人間が、自分に代わって何かを行うようソフトウェアに指示することです。
この定義では、制限付きアクセスについても言及しています。 であるため、自分の機能の一部だけを委任できることを想像できます。
そして、HTTP サービスについて言及して締めくくります。 .この承認委任は、HTTP サービスで行われます .

OAuth2 の前の委任

コンテキストがより明確になったので、次のことを自問できます。OAuth2 や類似の概念が登場する前は、どのように行われていたか

まあ、ほとんどの場合、それはご想像のとおり悪いものでした:共有シークレット .

ソフトウェア A にサーバー B 上の自分のものへのアクセスを許可したい場合、ほとんどの場合、ソフトウェア A にユーザー/パスを与えて、ソフトウェアが自分に代わって使用できるようにするというアプローチが取られました。これは今でも多くの最新のソフトウェアで見られるパターンであり、個人的には不快に感じることを願っています。 秘密を共有すれば、それはもはや秘密ではありません!

代わりに、何かを共有する必要があるサービスごとに、新しい管理者とパスワードの組み合わせを作成できると想像してみてください。それらをアドホック パスワードと呼びましょう .特定のサービスのメイン アカウントとは異なりますが、同じサービスにアクセスすることができます。 この場合、委任することはできますが、作成する必要がある新しいアプリケーション専用アカウントをすべて追跡する責任があります。

OAuth2 – アイデア

私たちが解決しようとしているビジネス上の問題は「委任」の問題であることを念頭に置いて、アドホック パスワードのアイデアを拡張して、これらのアドホック パスワードを管理する負担をユーザーから取り除きたいと考えています。
OAuth2 はこれらのアドホックを呼び出します パスワード トークン .
トークンは、実際にはそれ以上のものです 、説明しようと思いますが、アドホック はじめにパスワード。

OAuth2 – コア ビジネス

Oauth 2 コア ビジネスの概要:

  • トークンの入手方法

OAuth2 – トークンとは?

すべてがトークンに焦点を当てているように見えるので、トークンとは何でしょう?
アドホック パスワードの類推を既に使用しましたが、これはこれまでのところうまくいきましたが、もっとうまくできるかもしれません.
OAuth2 仕様内の答えを探しますか?
さて、がっかりする準備をしてください。 OAuth2 仕様では、トークンを定義する方法の詳細は提供されません。なぜこれが可能なのでしょうか?
OAuth2 は「単なるフレームワーク」であると言ったのを覚えていますか?これは、その定義が重要な状況の 1 つです!
仕様は、トークンとは何かの論理的な定義を示し、それが持つ必要のある機能の一部を説明するだけです.
しかし、最後に、仕様によると、トークンは文字列です。リソースにアクセスするための認証情報を含む文字列。
もう少し詳しく説明しますが、ほとんどの場合、トークンに何が含まれているかはあまり重要ではないと言えます。アプリケーションがそれらを消費できる限り。

トークンとは、関心のあるリソースにアプリケーションがアクセスできるようにするものです。

トークンとは何かを考えすぎないようにする方法を指摘するために、仕様では「通常、クライアントには不透明である」と明示的に述べられています。彼らは、あなたがそれらを理解する必要さえないと実際に言っています!覚えておくべきことが少なくて済みますが、悪くはありません。

しかし、これが純粋な哲学の教訓にならないように、トークンとは何かを示しましょう。

{
   "access_token": "363tghjkiu6trfghjuytkyen",
   "token_type": "Bearer"
}

ざっと見てみると、ええ、それは文字列であることがわかります。 JSON ライクですが、これはおそらく json が最近人気があるためであり、必ずしも要件ではありません。 id:06 というランダムな文字列のように見えるセクションを見つけることができます。 .プログラマーは、このようなものを見たとき、少なくとも文字列が長すぎない場合は、それが別の場所に保存されている、より詳細な情報と関連付けることができる単なるキーであることを示している可能性があることを知っています。そして、それはこの場合にも当てはまります。より具体的には、追加情報は、そのコードが表す特定の承認に関する詳細です。

15:15 .

あなたの合理的な質問は次のとおりです:27 の特徴は何ですか? トークンタイプ?他の種類はありますか?どれ?

幸いなことに、物事をシンプルに保つための努力のおかげで、答えは簡単です (混乱しやすいと言う人もいるかもしれません…)。

仕様は 39 についてのみ述べています トークンタイプ!

では、なぜこのようにトークンを設計した人は、唯一の既知の値を指定する必要があると感じたのでしょうか?ここでパターンが見え始めるかもしれません:OAuth2 は単なるフレームワークだからです!
それは、物事を行う方法を提案し、いくつかの選択を行うための面倒な作業の一部を行いますが、最後に、フレームワークを使用して必要なものを構築する責任があります。
ここでは 46 についてしか話していませんが、ただ言っているだけです。 カスタム型を定義できないという意味ではなく、それに属性を与えることが許可されているという意味です。

さて、シングルタイプです。 しかし、それは奇妙な名前です .名前は関連するものを暗示していますか?ばかげた質問かもしれませんが、私のような英語を母国語としない人にとっては、56 この場合の手段は少し混乱する可能性があります。

その意味は実際には非常に単純です。

ベアラー トークンは、有効なトークンを持っている場合に信頼できるものです。質問はありません。

シンプルすぎて迷います。 「まあ、現実世界のすべてのトークンのようなオブジェクトはそのように機能します。もし私が有効なお金を持っていれば、あなたはそれらをあなたが販売する商品と交換します」.

正しい。これは、ベアラー トークンの有効な例です。

しかし、すべてのトークンが親切な Bearer であるとは限りません。 たとえば、航空券は Bearer トークンではありません。 飛行機に搭乗できるチケットを持っているだけでは十分ではありません .また、チケットを照合できるように、有効な ID を提示する必要があります。乗車券と名前が一致し、IDカードと顔が一致すれば、乗車できます。

これをまとめるために、トークンの 1 つを持っていれば、リソースへのアクセスを取得するのに十分である、一種のトークンを使用しています。

念のために言っておきますが、OAuth2 は委任に関するものであると述べました。この特性を持つトークンは、委任する人に渡したい場合に明らかに便利です。

トークンのアナロジー

繰り返しますが、これは英語を母国語としない私のバックグラウンドであり、明確にする必要があるかもしれません。私の母国語であるイタリア語でトークンの最初の翻訳を検索すると、物理的なオブジェクトが示されます。このようなもの:

具体的には、公衆電話ボックスで電話をかけるために使用される古いトークンです。ベアラー トークンであるにもかかわらず、OAuth2 トークンとの類似性は非常に低いです。
Tim Bray によって、この古い投稿で、はるかに優れた図が設計されています。ホテル キーはアクセス トークンです。直接読むことをお勧めします。記事ですが、主なアイデアは、最初にリンクした物理的な金属コインと比較して、ソフトウェアトークンは寿命があり、リモートで無効にでき、情報を運ぶことができるということです.

関係者

これらは私たちのアクターです:

  • リソース オーナー
  • クライアント (別名アプリケーション)
  • 認可サーバー
  • 保護されたリソース

アプリケーション:比較的直感的である必要があります 保護されたリソースにアクセスしたい リソース オーナーが所有 .そのためには、トークンが必要です。トークンは認証サーバーによって発行されます 、他のすべてのアクターが信頼するサード パーティ エンティティです。

通常、何か新しいものを読むとき、システムのアクターをすばやくスキップする傾向があります。おそらくそうすべきではありませんが、ほとんどの場合、たとえば「ユーザー」について説明している段落は、多くの単語を使用して、それが単なるユーザーであることを伝えています…直感的ではない用語を調べ、それらのいくつかに特に注意を払うべき独自の特徴があるかどうかを確認します。

OAuth2 固有のケースでは、最も紛らわしい名前のアクターはクライアントだと思います .
なぜそう言うのですか?通常の生活 (および IT) では、ユーザー、特殊なソフトウェア、非常に一般的なソフトウェアなど、さまざまな意味を持つ可能性があるためです。

アプリケーションとして分類したいと思います .

クライアントは、アクセス許可を委任するアプリケーションであることを強調します。たとえば、アプリケーションがブラウザ経由でアクセスするサーバー側のウェブ アプリケーションである場合、クライアントはユーザーやブラウザ自体ではありません。クライアントは、独自の環境で実行されているウェブ アプリケーションです。>

これはとても重要なことだと思います。クライアントという用語はいたるところにあるので、完全に置き換えるのではなく、クライアント =アプリケーションという関係を脳に覚えさせることをお勧めします。 .

また、別の非公式のアクター、ユーザー エージェントがあると思います。

ここで人々を混乱させないことを願っています。なぜなら、これは完全に私が自分のメンタル マップを構築するために使用するものだからです。 OAuth2 フローでこの 5 番目のアクターを識別するためです。
ほとんどの場合、ユーザー エージェントは Web ブラウザによって偽装されます。その責任は、互いに直接対話していない 2 つのシステム間で情報の間接的な伝達を可能にすることです。
A は B と対話する必要がありますが、そうすることが許可されていません。したがって、A は C (ユーザーエージェント) に B に何かを伝えるように指示します。

現時点ではまだ少し混乱しているかもしれませんが、後でこれを明確にできることを願っています。

OAuth2 コア ビジネス 2

OAuth2 は、トークンを取得する方法に関するものです。

あなたが OAuth2 の専門家でなくても、誰かがそのトピックについて言及するとすぐに、Google やその他の主要なサービス プロバイダーのページをすぐに思い浮かべるかもしれません。まだアカウントを持っていないので、そのサービスを信頼していて、委任したいことを Google に伝えてください。 Google でそのサービスに対して持っている権限の一部。

これは正しいですが、これは OAuth2 が定義する可能性のある複数の相互作用の 1 つにすぎません .

あなたが知っていることが重要な4つの主要なものがあります。初めて聞いた方は驚くかもしれません:
Google のような権限画面が表示されるわけではありません!
これは、コマンド ライン ツールからでも OAuth2 アプローチを活用したい場合があるためです。 UI がまったくなくても、アクセス許可を委任するためのインタラクティブな Web ページを表示できます。

もう一度覚えておいてください:主な目標はトークンを取得することです!

取得方法、つまり「方法」の部分を見つけて、それを使用できるようになれば、完了です。

前述したように、OAuth2 フレームワークによって定義された 4 つの方法があります。 フローと呼ばれることもあれば、助成金と呼ばれることもあります .
どのように呼ぶかは問題ではありません。 私は個人的にフローを使用しています トークンを取得するためにさまざまなアクターと実行する必要がある相互作用について、それらが互いに異なることを思い出させるのに役立つからです。

それらは次のとおりです。

  • 承認コードの流れ
  • 暗黙の付与フロー
  • クライアント クレデンシャル グラント フロー
  • リソース所有者認証情報付与フロー (別名パスワード フロー)

それらのそれぞれは、特定のシナリオの推奨されるフローです。
直感的な例を挙げると、クライアントが秘密を保持できる状況 (サーバー側の Web アプリケーション) と、技術的にそれが可能なその他の状況があります。 t (ブラウザでコードを完全に検査できるクライアント側の Web アプリケーション)。
今説明したような環境上の制約により、完全なフローで定義されたステップの一部が安全ではなくなります (そして役に立たなくなります)。したがって、単純にするために、不可能だった、またはセキュリティ関連の価値を追加していない対話の一部が完全にスキップされた場合に、他のフローが定義されています。

OAuth2 ポスター ボーイ:認証コード フロー

以下の 3 つの理由から、Authorization Code Flow についての説明を開始します。

  • これは最も有名なフローであり、すでに操作したことがあるかもしれません (Google のような委任画面です)
  • 最も複雑で、明確で、本質的に安全です
  • このフローと比較すると、他のフローの方が簡単に推論できます

認証コード フローは、クライアントが信頼され、秘密を保持できる場合に使用する必要があるフローです。これは、サーバー側の Web アプリケーションを意味します。

Authorization Code Flow でトークンを取得する方法

<オール>
  • 関係するすべてのアクターが承認サーバーを信頼する
  • ユーザー (リソース所有者) は、クライアント (アプリケーション) に自分の代わりに何かをするように指示します
  • クライアントは、いくつかのパラメーターを追加して、ユーザーを承認サーバーにリダイレクトします:64718690
  • 認証サーバーは、特定の権限 (スコープ) を使用して、ユーザーに代わってリソースへのアクセス (委任) をクライアントに許可するかどうかをユーザーに尋ねます。
  • ユーザーが委任リクエストを受け入れると、認証サーバーはクライアントの URL にリダイレクトするようにユーザー エージェント (ブラウザ) に指示を送信します。 103 も注入します この HTTP リダイレクト命令に挿入します。
  • HTTP リダイレクトのおかげでユーザー エージェントによってアクティブ化されたクライアントは、(ユーザー エージェントをバイパスして) 承認サーバーと直接通信するようになりました。 116122135 (転送されたこと)
  • 認証サーバーはクライアント (ブラウザではなく) に有効な 143 を返します そして 153
  • これは、OAuth2 ダンスとも呼ばれるほど明瞭です。

    いくつかの点に下線を引きましょう:

    • ステップ 2 では、他のパラメータの中で 168 を指定します .これは、アクターの 1 つとして User-Agent を導入したときに期待した間接通信を実装するために使用されます。両者の間で直接ネットワーク接続を開かずに、認可サーバーが情報をクライアントに転送できるようにする場合、これは重要な情報です。
    • 176 ステップ 2 で言及されているのは、クライアントが要求している権限のセットです
    • これは、クライアントが完全に保護されている場合に使用するフローです。クライアントと認可サーバー間の通信が安全性の低いユーザー エージェント (通信を傍受または改ざんする可能性がある) を通過することを回避する場合、ステップ 5 のこのフローに関連しています。これが、クライアントがさらにセキュリティを有効にすること、つまり 186 を送信することが理にかなっている理由でもあります。 、それは彼と認可サーバーの間でのみ共有されます。
    • 194 クライアントが認可サーバーに対して実行する必要がある可能性のある後続の自動呼び出しに使用されます。現在の 208 の場合 有効期限が切れ、新しいものを取得する必要があり、有効な 217 を送信します 委任を確認するためにユーザーに再度尋ねることを避けることができます。

    OAuth2 トークンを取得したら、次は?

    OAuth2 は、覚えているフレームワークです。フレームワークは私に今何をするように指示しますか?

    まあ、何も。 =P

    クライアントの開発者次第です。

    彼女は次のことができます (そして多くの場合そうすべきです):

    • トークンがまだ有効かどうかを確認
    • 誰がこのトークンを承認したかについての詳細情報を調べる
    • そのトークンに関連付けられている権限を調べる
    • 最終的にリソースへのアクセスを許可することが理にかなっているその他の操作

    それらはすべて有効であり、かなり明白なポイントですよね?開発者は、次に実行する最適な一連の操作を自分で判断する必要がありますか?彼女は間違いなくできます。それ以外の場合は、OpenIDConnect(OIDC) という別の仕様を利用できます。これについては後で詳しく説明します。

    OAuth2 – 暗黙の付与フロー

    秘密を守れないクライアント アプリケーション向けに設計されたフロー .明らかな例は、クライアント側の HTML アプリケーションです。しかし、コードが一般に公開されているバイナリ アプリケーションでさえ、秘密を抽出するために操作される可能性があります。
    認証コード フローを再利用できなかったのでしょうか?はい、しかし… 秘密がもはや安全な秘密ではない場合、ステップ 5) のポイントは何ですか?その追加ステップからは何の防御も得られません!
    したがって、暗黙のグラント フローは認証コード フローに似ていますが、その無駄なステップ 5 は実行しません。
    目的は最初にコードを取得する中間ステップなしで access_tokens を直接取得する 、シークレットと共に交換され、access_token を取得します。

    222 を使用しています 認可サーバーに接続する際に使用するフローを特定します。また、236 がないことも .これは、(安全性の低い環境のため) ユーザー セッションが短くなり、いずれにせよ、委任する意志を再確認するためにユーザーがまだいると想定されているためです (これが、定義につながる主なユース ケースでした)。 241 の )。

    OAuth2 – クライアント認証情報の付与フロー

    リソース オーナーがいない場合、またはクライアント ソフトウェア自体と区別がつかない場合 (1 対 1 の関係) はどうなりますか?
    別のバックエンド システムと通信したいだけのバックエンド システムを想像してみてください。ユーザーは関与しません。このような対話の主な特徴は、何かを委任する意志を確認するように求められるユーザーがいなくなったため、もはや対話的ではないということです。また、アクティブなユーザーが機密情報を読み取るリスクを心配する必要がない、より安全な環境を暗黙のうちに定義しています。

    その型は 252 です .

    ここでは詳しく説明しませんが、存在することに注意してください。前のフローと同様に、これは完全な OAuth ダンスのバリエーションであり、実際には単純化されたものであり、シナリオで許可されている場合に使用することをお勧めします。

    OAuth2 – リソース所有者認証情報付与フロー (別名パスワード フロー)

    混乱しそうなので、ここに注目してください。

    これがシナリオです:リソース所有者は認可サーバーにアカウントを持っています。リソース所有者は、アカウントの詳細をクライアントに提供します。クライアントはこの詳細を使用して、認可サーバーへの認証を行います…

    =O

    ディスカッションを最後まで読んだことがあれば、冗談を言っているのかと思うかもしれません。 これはまさに、OAuth2 調査の開始時に回避しようとしたアンチ パターンです!

    可能な推奨フローとしてここにリストされていることをどのように見つけることができますか?

    実際、答えは非常に合理的です。レガシー システムからの移行の最初のステップとなる可能性があります .実際には、共有パスワード アンチパターンよりも少し優れています。
    パスワードは共有されますが、それはトークンを取得するために使用される OAuth ダンスを開始するための手段にすぎません。

    これにより、より良い代替手段がない場合、OAuth2 がドアに足を踏み入れることができます。 261 の概念を導入します 、より適切で安全なフローがトークンを取得できるように、アーキテクチャが十分に成熟するまで (または環境が変更されるまで) 使用できます。また、トークンは、保護されたリソース システムに到達するアドホック パスワードであることに注意してください。一方、完全に共有されたパスワード アンチパターンでは、転送する必要があるのは私たちのパスワードでした。

    したがって、理想にはほど遠いですが、少なくともいくつかの基準によって正当化されました。

    最適なフローの選び方

    インターネット上には多くの意思決定フロー図があります。私が最も気に入っているものの1つはこれです:

    https://auth0.com から

    ここで説明した簡単な説明を思い出し、環境に基づいて最も簡単なフローを選択するのに役立つはずです。

    OAuth2 トークンに戻る – JWT

    これで、トークンを取得できるようになりました。それらを取得する方法は複数あります。それらをどう処理するかは明示的に指示されていませんが、追加の努力と認可サーバーへの追加の呼び出しがあれば、何かを調整して有用な情報を取得できます。

    物事は良くなるでしょうか?

    たとえば、トークンが次のようになると仮定しました:

    {
       "access_token": "363tghjkiu6trfghjuytkyen",
       "token_type": "Bearer"
    }

    認可サーバーへのラウンドトリップを節約するために、より多くの情報を含めることはできますか?

    次のようなものが良いでしょう:

    {
      "active": true,
      "scope": "scope1 scope2 scope3",
      "client_id": "my-client-1",
      "username": "paolo",
      "iss": "http://keycloak:8080/",
      "exp": 1440538996,
      "roles" : ["admin", "people_manager"],
      "favourite_color": "maroon",
      ... : ...
    }

    リソース所有者の委任に関連する一部の情報に直接アクセスできます。

    幸いなことに、他の誰かが同じ考えを持っていて、彼らは JWT (JSON Web トークン) を発表しました。
    JWT は、一連のクレームを表す JSON ベースのトークンの構造を定義するための標準です。まさに私たちが探していたものです!

    実際、JWT 仕様が提供する最も重要な側面は、上で例示したペイロードではなく、Authorizatin Server を使用せずにトークン全体を信頼できる機能です!

    それはどのように可能ですか?このアイデアは新しいものではありません。JOSE 仕様による JWT のコンテキストで定義された非対称署名 (pubkey) です。

    これを更新させてください:

    非対称署名では、情報の有効性を検証するために 2 つの鍵が使用されます。
    これら 2 つの鍵は結合されていますが、一方は文書の作成者だけが知っている秘密鍵であり、もう一方は公開されています。
    秘密鍵はドキュメントの指紋を計算するために使用されます。ハッシュ。
    ドキュメントが送信先に送信されると、リーダーは秘密鍵に関連付けられた公開鍵を使用して、受け取ったドキュメントとフィンガープリントが有効かどうかを確認します。
    デジタル署名アルゴリズムが伝える対応する秘密鍵によって署名されている場合にのみ、公開鍵に従ってドキュメントが有効であることがわかります。

    全体的な考え方は、ローカル検証に合格した場合、メッセージが秘密鍵の所有者によって発行されたことを確認できるため、暗黙的に信頼されているということです。

    トークンの使用例に戻ります。

    トークンを受け取ります。このトークンを信頼できますか?トークンをローカルで検証します 、発行者に連絡する必要はありません。信頼できる公開鍵に基づく検証に合格した場合にのみ、トークンが有効であることを確認します。質問はありません。トークンがデジタルサイネージに従って有効であり、宣言された寿命に従って生きている場合、それらの情報を真とみなすことができ、認可サーバーに確認を求める必要はありません!

    ご想像のとおり、このすべての信頼をトークンに置いているため、寿命が過度に長いトークンを発行しない方が賢明かもしれません:
    誰かが認可サーバーで委任設定を変更した可能性があります。クライアントにはまだ有効で署名されたトークンがあり、その決定の基にすることができます。長期間にわたって信頼されるリスク。

    OpenID コネクト

    このセクションがあなたを失望させないことを願っていますが、この記事はすでに長く、情報がぎっしり詰まっているので、わざと短くします。

    OAuth2 + JWT + JOSE ~=OpenID Connect

    繰り返しますが、OAuth2 はフレームワークです。
    OAuth2 フレームワークは、JWT 仕様、JOSE、およびここでは詳しく説明しない他のアイデア、create OpenID Connect 仕様と組み合わせて使用​​されます。

    ここで定義した最善のアプローチとアイデアがまとめられているため、OpenID Connect の使用と活用に関心を持っていることが多いということです。
    OAuth2 を活用していますが、は、OpenID Connect のより明確な境界であり、プレーンな OAuth2 ではカバーされなかった、より豊富なトークンと認証のサポートを提供します。

    一部のオンライン サービスでは、OAuth2 または OpenID Connect のいずれかを選択できます。それはなぜでしょうか?
    彼らが OpenID Connect について言及するとき、あなたは標準を使用していることを知っています。実装を切り替えても同じように動作するもの.より一般的な OAuth2 フレームワークです。
    そのため、選択には注意してください。

    結論

    このトピックに興味がある場合、またはこの記事でさらに混乱した場合は、Justin Richer と Antonio Sanso による OAuth 2 in Action を確認することをお勧めします。知識があり、それをオープンソースの認証サーバーに適用したい場合は、ここで説明したすべての機能を備えた Keycloak を試すことを強くお勧めします。

    Java タグ