先日Windows Server 2016のTechnical Preview 4が出たので、AD FSがどうなったのかを見ていきたいと思います。
まずOpenID ConnectのRP(Relying Party)を作る上で個人的に一番気になっていたTokenエンドポイントのクライアント認証を見てみました。
一般的なRPの開発ドキュメントを見ているとOAuth2.0のCode Flowを使う際、code取得後にTokenエンドポイントへのPOST時のクライアント認証はBASIC認証で実装されていることが多いですし、RFCのサンプルもそうなっているのですが、Azure Active DirectoryやAD FSのTokenエンドポイントはBASIC認証をサポートしていませんでした。
Windows Server 2016ではこのあたりが改修されることになっており、前回のTechnical Preview 3の.well-known/openid-configurationを見ると以下のようにclient_secret_basicもサポートされていることがわかります。
"token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],
しかし、Technical Preview 3で実際にTokenエンドポイントでBASIC認証を使おうとすると、invalid_clientと言われてHTTP 400が返ってきてしまいました。
ということで、今回出たTechnical Preview 4ではどこまで治ったのかを見てみます。
codeを取得した後、TokenエンドポイントへのPOST時のAuthorizationヘッダにclient_idとclient_secretを":"で接続してbase64エンコードした文字列をBasicに続けて設定します。
結果、いけました!
これでこれまで他のOpenID Provider向けに作ったクライアントをAD FS用に変更する必要がなくなりましたね。
ただ、現状までAzure ADはまだclient_secret_postとprivate_key_jwtしかサポートしていないみたいです。今後に期待ですね。。
0 件のコメント:
コメントを投稿