OpenID Connect: カスタムから標準までの内部アプリケーションの承認

数か月前、私は何百もの社内アプリケーションへのアクセスを管理するために OpenID Connect サーバーを実装していました。 小規模で便利な独自の開発から、一般に受け入れられている標準に移行しました。 中央サービスを介したアクセスにより、単調な操作が大幅に簡素化され、認証の実装コストが削減され、多くの既製のソリューションを見つけて、新しいソリューションの開発に頭を悩ませる必要がなくなります。 この記事では、この移行と、私たちがなんとか埋めることができた問題について説明します。

遠い昔...すべてはどのように始まったのか

数年前、手動制御するには社内アプリケーションが多すぎたとき、私たちは社内のアクセスを制御するアプリケーションを作成しました。 これは従業員に関する情報を含むデータベースに接続する単純な Rails アプリケーションで、さまざまな機能へのアクセスが構成されていました。 同時に、クライアント側と認可サーバー側からのトークンの検証に基づいた最初の SSO を確立しました。トークンは、いくつかのパラメーターを使用して暗号化された形式で送信され、認可サーバーで検証されました。 これは、最も便利なオプションではありませんでした。各内部アプリケーションはかなりのロジック層を記述する必要があり、従業員データベースは認可サーバーと完全に同期されていたからです。

しばらくしてから、集中認証のタスクを簡素化することにしました。 SSO がバランサーに転送されました。 OpenResty の助けを借りて、トークンをチェックし、リクエストがどのアプリケーションに送信されるかを認識し、そこにアクセスがあるかどうかを確認できるテンプレートが Lua に追加されました。 このアプローチにより、内部アプリケーションへのアクセスを制御するタスクが大幅に簡素化され、各アプリケーションのコードに追加のロジックを記述する必要がなくなりました。 その結果、外部からのトラフィックを遮断し、アプリケーション自体は認可について何も知りませんでした。

しかし、XNUMX つの問題が未解決のまま残されました。 従業員に関する情報が必要なアプリケーションについてはどうでしょうか? 認可サービス用の API を作成することは可能ですが、その場合、そのようなアプリケーションごとに追加のロジックを追加する必要があります。 さらに、社内の認証サーバー上で、後にオープンソースに変換される自社作成アプリケーションの XNUMX つへの依存を解消したいと考えていました。 それについてはまた別の機会にお話します。 両方の問題に対する解決策は OAuth でした。

共通の基準に合わせて

OAuth は理解しやすく、一般に受け入れられている認証標準ですが、その機能だけでは十分ではないため、すぐに OpenID Connect (OIDC) の検討を開始しました。 OIDC 自体は、オープン認証標準の 2.0 番目の実装であり、OAuth XNUMX プロトコル (オープン認可プロトコル) 上のアドオンに組み込まれました。 このソリューションにより、エンド ユーザーに関するデータの欠如の問題が解決され、認可プロバイダーの変更も可能になります。

ただし、特定のプロバイダーを選択せず​​、既存の認可サーバーに OIDC との統合を追加することにしました。 この決定を支持したのは、OIDC がエンド ユーザーの認証に関して非常に柔軟であるという事実でした。 したがって、現在の認可サーバーに OIDC サポートを実装することができました。

独自の OIDC サーバーの実装方法

1) データを希望の形式に変換します

OIDC を統合するには、現在のユーザー データを標準で理解できる形式にする必要があります。 OIDC では、これをクレームと呼びます。 クレームは基本的にユーザー データベースの最終フィールド (名前、電子メール、電話番号など) です。 存在する スタンプの標準リスト、このリストに含まれていないものはすべてカスタムとみなされます。 したがって、既存の OIDC プロバイダーを選択する場合に注意する必要がある最初の点は、新しいブランドの便利なカスタマイズの可能性です。

ホールマークのグループは、次のサブセットであるスコープに結合されます。 認可中は、スコープ内の一部のブランドが必要ない場合でも、特定のブランドではなくスコープへのアクセスが要求されます。

2) 必要な助成金の実施

OIDC 統合の次の部分は、認可タイプ、いわゆるグラントの選択と実装です。 選択したアプリケーションと認可サーバー間の対話のさらなるシナリオは、選択した許可によって異なります。 適切な許可を選択するための例示的なスキームを以下の図に示します。

最初のアプリケーションでは、最も一般的な許可である認証コードを使用しました。 他のものとの違いは、XNUMX つのステップであることです。 追加の検査を受けています。 まず、ユーザーは認証許可を要求し、トークン (認証コード) を受け取ります。次に、このトークンを使用して、旅行のチケットと同様に、アクセス トークンを要求します。 この認可スクリプトの主な対話はすべて、アプリケーションと認可サーバー間のリダイレクトに基づいています。 この助成金について詳しく読むことができます ここで.

OAuth は、認可後に取得されるアクセス トークンは一時的なものであり、できれば平均して 10 分ごとに変更されるべきであるという概念に準拠しています。 認証コードの付与は、リダイレクトによる 10 段階の検証であり、XNUMX 分ごとにこのような段階を実行するのは、正直言って、あまり快適な作業ではありません。 この問題を解決するために、別の補助金、つまり我が国でも使用したリフレッシュ トークンがあります。 ここではすべてが簡単です。 別の許可からの検証中に、メインのアクセス トークンに加えて、別のアクセス トークンが発行されます。リフレッシュ トークンは XNUMX 回だけ使用でき、通常はその有効期間がはるかに長くなります。 このリフレッシュ トークンを使用すると、メイン アクセス トークンの TTL (Time to Live) が終了すると、新しいアクセス トークンのリクエストが別のグラントのエンドポイントに届きます。 使用されたリフレッシュ トークンはすぐにゼロにリセットされます。 このチェックは XNUMX 段階で行われ、ユーザーには気づかれないようにバックグラウンドで実行できます。

3) カスタムデータ出力形式を設定する

選択した付与が実装された後、承認が機能します。エンド ユーザーに関するデータの取得について言及する価値があります。 OIDC にはこのための別のエンドポイントがあり、そこで現在のアクセス トークンとそれが最新であるかどうかを使用してユーザー データをリクエストできます。 また、ユーザーのデータがそれほど頻繁に変更されず、現在のデータを何度も追跡する必要がある場合は、JWT トークンなどのソリューションを利用できます。 これらのトークンは標準でもサポートされています。 JWT トークン自体は、ヘッダー (トークンに関する情報)、ペイロード (必要なデータ)、署名 (署名。トークンはサーバーによって署名され、後でその署名のソースを確認できます) の XNUMX つの部分で構成されます。

OIDC 実装では、JWT トークンは id_token と呼ばれます。 通常のアクセス トークンと一緒にリクエストすることができ、あとは署名を検証するだけです。 認可サーバーには、次の形式の公開鍵を含む別のエンドポイントがあります。 J.W.K.。 これに関して言えば、標準に基づいた別のエンドポイントがあることに言及する価値があります。 RFC5785 OIDC サーバーの現在の構成を反映します。 これには、すべてのエンドポイント アドレス (署名に使用される公開キー リングのアドレスを含む)、サポートされているブランドとスコープ、使用されている暗号化アルゴリズム、サポートされている許可などが含まれます。

たとえば、Google では次のようになります。

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
 "token_endpoint": "https://oauth2.googleapis.com/token",
 "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
 "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 "response_types_supported": [
  "code",
  "token",
  "id_token",
  "code token",
  "code id_token",
  "token id_token",
  "code token id_token",
  "none"
 ],
 "subject_types_supported": [
  "public"
 ],
 "id_token_signing_alg_values_supported": [
  "RS256"
 ],
 "scopes_supported": [
  "openid",
  "email",
  "profile"
 ],
 "token_endpoint_auth_methods_supported": [
  "client_secret_post",
  "client_secret_basic"
 ],
 "claims_supported": [
  "aud",
  "email",
  "email_verified",
  "exp",
  "family_name",
  "given_name",
  "iat",
  "iss",
  "locale",
  "name",
  "picture",
  "sub"
 ],
 "code_challenge_methods_supported": [
  "plain",
  "S256"
 ],
 "grant_types_supported": [
  "authorization_code",
  "refresh_token",
  "urn:ietf:params:oauth:grant-type:device_code",
  "urn:ietf:params:oauth:grant-type:jwt-bearer"
 ]
}

したがって、id_token を使用すると、必要なすべてのホールマークをトークンのペイロードに転送でき、ユーザー データを要求するたびに認可サーバーに接続する必要がなくなります。 このアプローチの欠点は、サーバーからのユーザー データの変更がすぐに反映されず、新しいアクセス トークンとともに反映されることです。

実施結果

そこで、独自の OIDC サーバーを実装し、アプリケーション側でそのサーバーへの接続を構成した後、ユーザーに関する情報の転送の問題を解決しました。
OIDC はオープンスタンダードであるため、既存のプロバイダーまたはサーバー実装を選択するオプションがあります。 Keycloak を試してみましたが、設定が非常に便利であることが判明しました。アプリケーション側で接続設定を設定および変更すると、準備が整います。 アプリケーション側で残っているのは、接続構成を変更することだけです。

既存のソリューションについて話す

私たちの組織内では、最初の OIDC サーバーとして独自の実装を組み立て、必要に応じて補足しました。 他の既製のソリューションを詳細に検討した結果、これは議論の余地があると言えます。 独自のサーバーを実装するという決定を支持する一方で、プロバイダー側​​には、必要な機能がないこと、および一部のサービスに対して異なるカスタム認証が存在する古いシステムが存在することへの懸念がありました。の従業員に関するデータがすでに保存されていました。 ただし、既製の実装には統合に便利な機能があります。 たとえば、Keycloak には独自のユーザー管理システムがあり、データはそこに直接保存されるため、そこにあるユーザーを追い抜くことは難しくありません。 これを行うために、Keycloak には、必要なすべての転送アクションを完全に実行できる API が用意されています。

私の意見では、認定された興味深い実装のもう XNUMX つの例は、Ory Hydra です。 さまざまなコンポーネントで構成されているので興味深いです。 統合するには、ユーザー管理サービスを認証サービスにリンクし、必要に応じて拡張する必要があります。

Keycloak と Ory Hydra だけが既製のソリューションではありません。 OpenID Foundation によって認定された実装を選択するのが最善です。 これらのソリューションには通常、OpenID 認定バッジが付いています。

OIDC サーバーを維持したくない場合は、既存の有料プロバイダーについても忘れないでください。 今では良い選択肢がたくさんあります。

次のステップ

近い将来、別の方法で内部サービスへのトラフィックを閉鎖する予定です。 OpenResty を使用してバランサー上の現在の SSO を OAuth ベースのプロキシに転送する予定です。 ここにはすでに多くの既製のソリューションがあります。たとえば、次のとおりです。
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

追加資料

jwt.io – JWTトークンを検証する優れたサービス
openid.net/developers/certified - 認定された OIDC 実装のリスト

出所： habr.com