このエントリは2019/10/22現在の情報に基づいています。将来の機能追加・変更に伴い、記載内容との乖離が発生する可能性があります。
はじめに
先日までの一連のエントリでは、API Management（以下、APIM）で公開しているAPIに対してOAuth2やOpenID Connectを使って認証・認可する仕組みを確認したが、今度は保護されたバックエンドサービスをAPIとして公開する場合にどうするかを確認する。
この場合、以下の2方法が考えられる。
- API呼び出しに使われるBearer tokenを、そのままバックエンドサービスに渡しても問題ない場合
- バックエンドサービスがAPI呼び出しとは別の認証・認可のスキームを使っている場合
API Gatewayがリバースプロキシとして機能する場合、Authorizationなどのヘッダーはバックエンドに流通しないようなサービスや製品もある（ふつうはAuthorizationヘッダーを後段に伝播しない）が、APIMの場合は流通できる。そのため、1の場合はTokenを後段に伝播して個々のバックエンドサービスでTokenを解釈すればよく、APIMで考慮すべきポイントは特にない。
対して2の場合、バックエンドサービスとAPI Gateway間で認証・認可が確立している必要があるため、種々の方策が考えられる。何れにしても、Tokenをどのように取得し、付加してBackend serviceを呼び出すか、が肝。
基本認証の場合（そもそも認証じゃないけど）
authentication-basic ポリシーを使う。
基本認証 / Authenticate with Basic
https://docs.microsoft.com/azure/api-management/api-management-authentication-policies#Basic
証明書を使う場合
authentication-certificate ポリシーを使う。
クライアント証明書による認証 / Authenticate with client certificate
https://docs.microsoft.com/azure/api-management/api-management-authentication-policies#ClientCertificate
ドキュメントに記載の通り、事前にAPIMに証明書をアップロードしておく必要がある。証明書のアップロード方法は以下のドキュメントを参照。
クライアント証明書のアップロード / Upload a client certificate
https://docs.microsoft.com/azure/api-management/api-management-howto-mutual-certificates#-upload-a-client-certificate
認証に使う証明書は、thumbprintもしくはリソース名で指定する。
Managed Identityを使う場合
authentication-managed-identity ポリシーを使う。
なお、証明書やManaged Identityを使う方法が同じWebページに記載があるが、これらについては、別のエントリで記載する。
OAuth2やOpenID Connectの場合
そのものズバリのポリシーはないが、send-request ポリシーを使ったサンプルがドキュメントに掲載されている。
ゲートウェイとバックエンド間の承認に OAuth2 を使用する / Use OAuth2 for authorization between the gateway and a backend
https://docs.microsoft.com/azure/api-management/policies/use-oauth2-for-authorization
が、GitHubにも種々のサンプルがあるので、こちらを参考にして実装する（サンプルでしかないので、例外処理やテストは当然実施しなければならない）。
Azure API Management Policy Snippets
https://github.com/Azure/api-management-policy-snippets/tree/master/examples
他社製品やサービスの場合、バックエンドサービスの認証ポリシーにOAuth2に対応したものもあるのだが、APIMではまだの様子…。
Logico Inside 