AWS puts IAM's OIDC discovery endpoints behind PrivateLink
Serguey Asael Shinder2 min readAWS has made the OpenID Connect discovery endpoints of IAM outbound identity federation reachable through interface VPC endpoints, announced on 25 September. Both the discovery metadata document and the JSON Web Key Set that holds the verification keys can now be fetched over AWS PrivateLink, so the traffic stays on the AWS network. It is available in all commercial regions, in GovCloud (US) and in the China regions, with no charge beyond normal PrivateLink pricing.
Outbound identity federation is the reverse of the usual arrangement. Instead of an external identity provider issuing tokens that AWS accepts, an AWS workload asks the Security Token Service for a short-lived JSON Web Token and presents it to some other service, which checks the signature against keys published at the OIDC discovery endpoints. The point is to stop storing long-lived API keys for third-party systems. Until now the verifying side had to reach those endpoints over the public internet. A verifier running in a VPC with no internet egress - the normal state for regulated workloads - could not fetch the keys at all, and had to be given a NAT path or a proxy just for that.
What it means
This is a small launch that closes a real gap in a pattern AWS is pushing hard. If you run both ends on AWS - say a workload in one account presenting a token to a service you host in another account's private subnets - the verifier can now be fully isolated. Before, the only public network dependency in the whole flow was the one component whose job was security.
It also changes a design decision worth revisiting. Teams that avoided outbound federation because their verifiers had no egress, and kept static credentials instead, no longer have that reason. When migrating, remember that a JWKS endpoint is something verifiers cache: set a sensible cache lifetime, handle key rotation by refetching on an unknown key ID rather than on a timer alone, and test what happens when the VPC endpoint is unavailable, because a verifier that cannot load keys should fail closed.
For external services - a SaaS vendor verifying tokens from its customers' AWS workloads - nothing changes: they sit outside your VPC and keep using the public endpoints. The launch helps the case where the verifier is yours.