してアプリケーションを認証するtakこんにちは、DWS2人目の大島です。認証を設定する機会があったのですが、インターネット上の検索では古い情報が散見されたため、最新の内容をまとめてみました。アイデンティティをそのまま、社内アプリケーションに流用したい、といったケースは多いかと思います。基づいた新しいフローが整備されています。拡張した古いフローに基づいた記事がヒットすることが多いです。ベースとした新しいフローとなっていますので、公式の推奨通り、新しいフローを使用していきましょう。Slackでは、新しいフローを確認していきましょう。今回は簡易的な検証を目的とするので、フロントエンドのコードは用意せず、バックエンドのみとします。フロントエンドを実装する前提でのバックエンドの準備となります。それぞれ独立したエンドポイントとなるので、認証が必要になります。利用するためには、クライアントアプリケーション(アプリケーション用のアイデンティティ)で認証をする必要があります。スコープなどを事前に登録しておきます。払い出して、クッキーを使用してセッションを管理する想定です。フローには関わってこないので、触れません。実装をイメージだけしておきます。OIDCのサインインフローは「認可コードフロー」と呼ばれるものとなります。直接トークンを払い出すのではなく、トークンと引き換え可能な認可コードを払い出して利用するフローです。簡単に「認可コードフロー」ついて確認しておきましょう。登場人物として「リライングパーティ(RP)」・「IDプロバイダ(IdP)」が存在します。「IDプロバイダ」は、IDを提供するサービス、と認識しておくと理解が早いかと思います。事前に設定などをした「リダイレクトURI」と呼ばれるエンドポイントへ、ユーザーをリダイレクトするのですが、その時にクエリパラメーターとして認可コードを返します。その後、その認可コードをアプリケーションにてトークンと引き換えることでフローが完了します。して使用し、フロントとバックエンドを用意するアプリケーションの具体的なフローを見ます。先ほどの図で、「リライングパーティ(RP)」はアプリケーションだったので、一つの図形で表していましたが、今回はフロントエンドとバックエンドを分けるので、図としてもそのように表現します。フロー自体は大きく変わっている部分はないのですが、フロントエンドとバックエンドで一部やり取りが発生したり、トークンリクエストを実施するのがバックエンドだったり、と細かい部分で意識しておく点があります。したフロント&バックエンドアプリケーションにおけるフローフローは以下の通りです。ある/openid.connect.tokenメソッドを使用する)IDトークンを検証して、問題がなければセッションIDを払い出すここからそれぞれのフローを詳細に見ていきます。して以下に置いておきます。ボタンを押して開くと中身が見えます。アプリケーション管理画面へ移ります。Apps↓の画面から、クライアントアプリケーションを作成していきます。ポップアップが表示されるので、画像の通り選択します。Permissionより、リダイレクトURIを入力します。これでクライアントアプリケーションの準備は完了です!最後に、クライアントIDとクライアントシークレットをコピーしておきましょう。それでは、本筋へ戻ります。/openid/connect/authorizeでの認証リクエストまず最初に、/openid/connect/authorizeへユーザーをリダイレクトし、アプリケーションが各種情報にアクセスしても良いか、ユーザー側の承諾を得ます。ログインが求められます。ログイン画面ログインが完了する、あるいは、ログインのセッションがある場合は、アプリケーションを利用しているとよく目にする以下のような、ユーザーに許可を求める画面が出てきます。アプリケーションへの同意画面アプリケーションのコードは以下のような感じです。今回、バックエンドで認証リクエストを開始するための、/sign-in-with-slackというエンドポイントを用意しました。認証リクエストで必要となる各種パラメーターをセットした上で、ユーザーをhttps://slack.com/openid/connect/authorizeへリダイレクトします。ドキュメントより、エンドポイントに対して送るパラメータは以下の通りです。https://slack.com参照:https://api.slack.com/authentication/sign-in-with-slack#request各種パラメーターの説明は以下の通りです。OIDCをどういったフローで行うかを指定します。認可コードフローなので、code一択となります。ユーザーが認可するアプリケーションがアクセス可能なリソースを記載します。攻撃を防止するためのランダムな値です。ユーザーとレスポンスを紐づけます。リプレイアタックを防止するためのランダムな値です。ユーザーとIDトークンを紐づけます。認可コードを返却するためのURIです。ユーザーをリダイレクトする際に、認可コードをパラメータとして返却します。ついては、今回の趣旨からは外れるので、詳細には取り扱いません。アプリのコードは単純にパラメータを付与してリダイレクトするだけですが、以下の通りです。フロントエンドから/sign-in-with-slackを叩くと、必要なパラメーターを付与してリダイレクトするような想定です。認可コードが、クエリパラメーターとしてリダイレクトURIに付与される形で返却されます。/openid.connect.tokenを使用して、トークンリクエストを実施します。Stepトークンリクエストをする際には、ざっくりと以下のパラメーターを渡します。アプリケーションのシークレットです。パスワードと同じようなものです。大きな理由の一つが、上述のclient_secretです。ようなフロントエンドでは、シークレットなどを安全には保管できません。叩くようにしています。アプリのコードは以下の通りです。今回リダイレクト先として、バックエンドに/callbackというエンドポイントを用意して、ここで認可コードを受け取ります。IDトークンが返却されます。ここで、IDトークンの検証を行います。Token)で返却されます。繋いだものとなります。JWTの構成IDトークンは、JWTで表現される(=署名を持つ)・仕様としてペイロードに持たなければならない要素、属性(クレームと呼ばれます)が決まっているので、トークンの正当性を検証することができる仕様となっています。して利用して、別アプリケーションの認証を行うといったことが安全にできるようになっています。IDトークンの中身は以下のような感じです。(ヘッダーとペイロード)マスクされた情報ばかりになってしまいますが、このように必要なクレームが格納されています。それぞれのクレームについてはここでは取り扱いません。false}IDトークンの検証については、以下の仕様にまとまってます。ここでは検証となるので簡単に、署名の検証・iss/audクレームの検証だけ行ってみようと思います。2アプリのコードは以下のような形になります。側が署名に使用した秘密鍵に対応する公開鍵が必要になります。Discoveryとjwks_urlというものです。関する情報を公開するエンドポイントを用意していることがあります。使用するために必要となる情報をJSON形式で得ることができます。場合、エンドポイントはhttps://slack.com/.well-known/openid-configurationとなります。endpoints試しにcurlを使ってエンドポイントへアクセスしてみると、以下のような情報が確認できます。]}トークン発行者(issuer)や認可エンドポイント(authorization_endpoint)、トークンエンドポイント(token_endpoint)などの情報が返ってきています。ここで今回確認したかった情報が、jwks_uriというものです。検証するために使われる公開鍵の情報を配布しているエンドポイントです。このエンドポイントから署名の検証に必要な鍵を取得して、IDトークンの内容が改ざんされてないか、確認をします。IDトークンの完全性が確認できたら、トークンの中のissとaudのクレームの検証も実行します。issは、issuerで、トークンの発行者(https://slack.com)が正しいのかどうかを確認します。audは、audienceでトークンの対象者(ここではクライアントID)が正しいのかどうかを確認しています。この検証によって、IDトークンの正当性が確認できたので、セッションIDを払い出して、ユーザーのログインセッションを管理します。フローに直接関わってくる部分ではないので割愛します。セッションIDを払い出さずとも、フロントエンドへ直接トークンを渡して、IDトークンの保有をキーとしてセッション管理をしても良いのではないか?という疑問も出てくるかもしれません。基本的に、基本的にトークンの有効期限は漏洩対策として短かく設定されており、ログインセッションの管理には向きません。IDトークンの有効期限は5分ほどですので、しっかりセッションIDを使用して管理しましょう。IDトークンを受け取って、検証を完了しました。して利用して、アプリケーションの認証をすることができました!最後に、今回使用したコードを置いてあるレポジトリを載せておきます。設定できないため、トークンの確認を行うためには、サーバーなどへのデプロイが必要です。して利用する方法について、ご紹介いたしました。フローは、なかなか最初は理解が難しく、取り付き辛さがあるかと思いますので、こちらの記事が理解の役に立てば、と思います。ウェブサービス株式会社(DWS)公式ブログ記事URLをコピーしました。