Microsoft Graph API に対するトークンは JWT のように見えるが、JWT ではないので、決して署名を検証しようとしてはいけない。

First Of All

業務等で使うなら素直に MSAL.PS や、Microsoft Graph PowerShell SDK を利用してトークン取得しましょう。
自分で実装しても勉強以外の役にはたぶん立たないです。

Windows 入ってたらとりあえず動くので、勉強会用にそれぞれのフローのコードを書いてみたのだが、勉強会する暇なくて腐ってたので供養。

本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2020 9日めの記事です。
最近プレビューとして実装された Azure AD の CAE という機能がある。

• ポリシーとセキュリティのリアル タイムな適用に向けて | Japan Azure Identity Support Blog

何のための機能か

もともと Azure AD で発行されるアクセス トークンは内包型トークンで、Azure AD の秘密鍵で署名されている。そのため RP はユーザーが提示したトークンについて、Azure AD に通信を行うことなく署名とクレームを検証することで正当性を確認できる。これは逆に言うとクライアントがトークンを一度取得すれば有効期限切れ (既定では 1 時間) まではリソースにアクセスし続けられる。

多くの場合この設計で問題となることは少ないが、以下のようなケースで問題となることがある。

Authorization Code Flow with PKCE に対応した MSAL.js 2.x がプレビューでリリースされていたので、触ってみたメモ。

Azure ポータルのアプリの登録画面

Azure AD のアプリ登録の画面がアップデートしており、リダイレクト URI の登録に SPA が追加されていた。

Azure AD が発行するトークンをカスタマイズする方法を少し調べたのでメモ。

トークンのカスタマイズ

そもそも Azure AD のトークンのカスタマイズをする理由としては大きく分けると以下の 2 つだと思う。

1. 連携アプリに対して発行する ID トークン の属性を追加・既存の属性をカスタマイズする。
2. Azure AD に登録した Web API を利用する用に アクセス トークン をカスタマイズする。

前者はアプリ側で Azure AD の属性を使いたい場合に利用する。

この記事は認証認可アドベントカレンダー の6日目の記事です。

動機: やっぱ OIDC ネタと FIDO ネタが多いから、どっちも絡めたやつを書けばめっちゃウケるのでは？
→ Azure AD B2C に WebAuthn によるパスワードレス サインインを実装するサンプルあったなあ…

と、苦し紛れにネタをひねり出した結果、くっそニッチな記事になってしまった。