This is the second post in my series breaking down Germany’s federal API authorization blueprint for other governments to follow. The first post made the case that the whole thing rests on a single posture — profile, don’t invent. Today I want to show what that posture actually looks like when you make the first and most consequential decision: which authorization standard the entire federation is going to stand on.
The temptation for a government building this layer is almost irresistible: gather the requirements, look at the landscape, and design something bespoke that fits your administrative reality exactly. Germany considered that path and wrote down, in the very first architecture decision record, precisely why they rejected it. A self-defined OAuth profile, they noted, allows so many extension combinations that you inevitably create security risks, and it mandates an expensive, ongoing audit to prove the thing is even safe. You would be signing up to be your own standards body, in perpetuity, for a problem the rest of the world has already solved. That is the trap, and naming it is the first act of discipline.
So what did they choose? OAuth 2.0, moving toward OAuth 2.1, with a qualified FAPI 2.0 security profile on top. What I love about the ADR is that it doesn’t just declare a winner — it walks the losers. SAML was rejected because machine-to-machine authorization is barely standardized there, the XML assertions are computationally heavy, and the number of maintained implementations is shrinking. SPIFFE/SPIRE, which is genuinely good at workload identity, was rejected because it wants a SPIRE server and its own trust domain in every cluster, including every client’s — an operational non-starter across this many operators and locations. Kerberos, LDAP, and RADIUS were rejected because they do not scale to federated, tokenized, decoupled trust and are increasingly relegated to sitting behind an identity provider. Each rejection is a sentence or two, but together they are a map of every dead end an agency might wander into on its own.
FAPI 2.0 won for reasons that are worth memorizing, because they are the reasons any high-assurance API program should reach for it. It already combines the right OAuth extensions into a coherent, vetted profile designed for exactly this — a federated security architecture — so you are not hand-picking extensions and hoping the combination is sound. It has a large population of implementations that have been certified by the OpenID Foundation, which means interoperability is a tested property rather than a hope. There is a conformance test suite you can run your clients and servers against. And because it is an open profile over an open framework, you avoid the vendor lock-in that would otherwise creep in through your most security-critical layer. The one honest downside they record is that FAPI 2.0 still leaves a few choices open — so they wrote an additionally qualified profile that makes those remaining decisions once, for the whole federation, which is the entire point of doing this centrally.
Then they did something I wish more security programs did: they split the requirements by how much protection an API actually needs, and they derived each tier from an explicit threat model rather than from vibes. For APIs with a normal protection need, the profile is built on RFC 9700, the Best Current Practice for OAuth 2.0 Security, already pulling in the stable hardening from OAuth 2.1, with a companion attacker-model document you can consult to understand why each requirement exists. For APIs with a high or very high protection need, the profile is derived and extended from FAPI 2.0 and — this is the part that should make any security reviewer sit up — shown by formal analysis to satisfy the FAPI attacker model. The security properties are not asserted. They are proven against a written adversary. That is a standard of rigor most private-sector API programs never reach, sitting in a public government repository.
The lesson for anyone building this — and I am looking squarely at US and European agencies here — is that the highest-leverage artifact you can produce is not code and it is not a platform. It is a published profile: a short document that says “here is our nation’s API authorization baseline — OAuth 2.1 plus FAPI 2.0, these two tiers, derived from these attacker models” — with a conformance suite behind it. Everything else hangs off that. In fact, this is exactly where the governance-as-code work I have been doing plugs in: a profile like this can be encoded as a Spectral ruleset so that any agency’s OpenAPI can be linted for the profile’s MUST and SHOULD requirements, per tier, in CI — turning “enforceable and economically viable,” which is Germany’s own phrase for what they wanted, into something you can actually check on every commit instead of once a year in a review meeting.
Germany did not pick anything exotic. OAuth, FAPI, RFC 9700 — an American or European agency would not have to argue with a single one of these choices in front of its own security board. What they contributed was the composition and the reasoning: the decision to profile rather than invent, written down with the alternatives it beat. That document is the thing to copy first. Next in the series I will get into onboarding — how they made registering a new API client something a machine can do without a human ever opening a ticket, and why that, more than anything, is what turns a pile of secured APIs into an actual ecosystem.
