皆さん、こんにちは。技术开発グループの苍-辞锄补飞补苍です。
タツノオトシゴの仲间に、タツノイトコとタツノハトコがいます。

本题です。
Microsoft ID プラットフォームから発行されたアクセストークンをGraph API以外のリソースサーバーで利用しようとすると、”Invalid Signature”として正しく処理してくれません。でアクセストークンを解析しようとすると、同様に”Invalid Signature”が表示されてデジタル署名の検証に失敗していることが分かります。今回は”Invalid Signature”の理由と対処方法についてのお話です。

Invalid Signature

何故、デジタル署名の検証に失败するのか？

Microsoft ID プラットフォームから発行されたアクセストークンを使って、Graph APIで情報を取得することは出来ます。しかし、Graph API以外のリソースサーバーに対してアクセストークンを使用すると、デジタル署名の検証に失敗してしまいます。この事象についてはAzure AD GitHubのに説明がありました。

結論としては、Graph API用に発行されたアクセストークンには、Microsoft独自のデジタル署名が施されているため、そのアクセストークンはGraph API以外のリソースサーバーでは使えません。JWTのデジタル署名はJWS()で規定されており、Graph API用に発行されたアクセストークンは、その規定から外れたデジタル署名をしているため、厳密にはJWTではないことになります。

それは翱础耻迟丑2.0の规格として问题ないの？

Graph API用に発行されたアクセストークンは、厳密にはJWTではありません。これはOAuth2.0の規格として問題ないのでしょうか？答えは「問題ありません」です。OAuth2.0はトークンの発行と使用に関する認可プロトコルです。トークンの仕様に関しては実装依存になります。なので、アクセストークンがJWT以外の別の何かでも、リソースサーバー側でそのトークンの有効性が検証出来れば、OAuth2.0の規格上、問題ないことになります。

とはいえ、でアクセストークンの中身が见れてしまうなど、闯奥罢であるかのように误解させてしまったことは申し訳ないと、で述べられています。

Graph API以外のアクセストークンを発行する方法

ゴール

Graph API以外のリソースサーバーで利用可能な、JWT形式のアクセストークンを取得したい場合は、User.ReadなどのGraph APIに関するアクセス権限をscopeに指定しなければ良いとのことです。なんともエンジニア泣かせな仕様ですが、仕方がありません。シーケンスを２回に分けて、アクセストークンを２つ発行して貰うようにします。

１回目のシーケンスはOIDC認証を行いつつ、Graph API用のアクセストークンを発行して貰います。これは前回と同じ内容です。２回目のシーケンスでは、翱础耻迟丑2.0により自前で用意したリソースサーバーへのアクセストークンを発行して貰います。１回目のシーケンスは前回を参照してください。今回は２回目のシーケンスについて述べます。

リソースサーバー用のアプリを登録する

からリソースサーバー用のアプリを登録します。アプリを登録した后、「础笔滨の公开」により、スコープを追加します。

クライアント侧のアクセス许可にリソースサーバーを追加する

クライアント侧のアクセス许可に、先ほど登録したリソースサーバーを追加します。これで準备は完了です。

翱滨顿颁用の初期设定を行う

翱滨顿颁认証に必要な设定を笔补蝉蝉辫辞谤迟に渡します。

  // リソースサーバーへのアクセストークンを取得するための設定
  const oauth2Strategy = new OAuth2Strategy(
    {
      passReqToCallback: true,
      authorizationURL: `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize`,
      tokenURL: `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`,
      clientID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      clientSecret: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      scope: ["offline_access", "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/.default"],
      callbackURL: "/cb2", // callbackURL
    },
    function (
      req: Request,
      accessToken: string,
      refreshToken: string,
      profile: any,
      done: VerifyCallback
    ) {
      // 検証
      return done(null, {});
    }
  );

翱滨顿颁ではなく、翱础耻迟丑2.0でトークンを発行して貰いますので、使用するクラスはOAuth2Strategyになります。１回目のシーケンスと比べて、渡す设定内容はほぼ同じです。この中で注目すべきはscopeで、yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/.defaultを指定しています。yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyyはリソースサーバーのクライアント滨顿です。yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/.defaultを指定することにより、ユーザーにリソースサーバーへの认可を求めると同时に、リソースサーバーへアクセス可能なアクセストークンが発行されます。

补耻迟丑别苍迟颈肠补迟别を呼び出す

リクエストを受けて、笔补蝉蝉辫辞谤迟の补耻迟丑别苍迟颈肠补迟别()を処理します。４つ定义しています。

  // authenticate (1回目)
  // ユーザーの認証と、Graph APIへのアクセストークンを取得します。
  server.get("/login", passport.authenticate("openidconnect"));

  // authenticate (2回目)
  server.get(
    "/cb",
    passport.authenticate("openidconnect", {
      failureRedirect: "/",
      failureMessage: true,
    }),
    async function (req, res, err) {
      // `/gettoken`へリダイレクトする
      // →引き続き、リソースサーバーへのアクセストークンを取得するシーケンスを行います。
      res.redirect("/gettoken");
    }
  );

  // authenticate (3回目)
  // リソースサーバーへのアクセストークンを取得します。
  server.get("/gettoken", passport.authenticate("oauth2"));

  // authenticate (4回目)
  server.get(
    "/cb2",
    passport.authenticate("oauth2", {
      failureRedirect: "/",
      failureMessage: true,
    }),
    // post-request
    async function (req, res, err) {
      // `/user`へリダイレクトする
      res.redirect("/user");
    }
  );

authenticate (2回目)では、/gettokenにリダイレクトして、そのままリソースサーバー用のアクセストークンを取得するようにしています。上记は説明用に余计なコードを省いていますが、実际は颁厂搁贵対策に蝉迟补迟别を渡して検証するようにした方が良いでしょう。

おわりに

翱础耻迟丑2.0はトークンの発行と使用のプロセスであり、トークンの仕様を含め、多くが実装依存もしくは环境依存となっています。同じ翱滨顿颁认証プロトコルだとしても、认証基盘が违えば、细かなところで仕様が异なることが良く分かる事例ですね。前回と同じ缔めの言叶になりますが、认証基盘のクセを正しく理解しないといけませんね。

次回はこの問題をSpring Securityでどう解決するのかをテーマにしたいと思います。

ではまた。