--- title: Profile, Don't Invent: How Germany Chose OAuth 2.1 and... description: Germany's federal API authorization blueprint chose OAuth 2.1 and FAPI 2.0 over bespoke solutions, SAML, SPIFFE/SPIRE, Kerberos, and others. The architecture... canonical: https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Profile, Don't Invent: How Germany Chose OAuth 2.1 and FAPI 2.0 | daily.dev og:description: Germany's federal API authorization blueprint chose OAuth 2.1 and FAPI 2.0 over bespoke solutions, SAML, SPIFFE/SPIRE, Kerberos, and others. The architecture... og:url: https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb og:image: https://api.daily.dev/og/posts/QoirLIgJb.png og:image:alt: Profile, Don't Invent: How Germany Chose OAuth 2.1 and FAPI 2.0 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Profile, Don't Invent: How Germany Chose OAuth 2.1 and FAPI 2.0 **[API Evangelist](https://daily.dev/sources/apievangelist)** · 5 min read · 1 upvotes · 0 comments ## Summary Germany's federal API authorization blueprint chose OAuth 2.1 and FAPI 2.0 over bespoke solutions, SAML, SPIFFE/SPIRE, Kerberos, and others. The architecture decision record explains each rejection and why FAPI 2.0 won: it bundles vetted OAuth extensions, has OpenID Foundation-certified implementations, a conformance test suite, and avoids vendor lock-in. The blueprint splits requirements into two tiers — normal protection (RFC 9700) and high/very high protection (FAPI 2.0 with formal security analysis) — each derived from explicit threat models. The key takeaway is that the highest-leverage artifact for any government or enterprise API program is a published profile document encoding the baseline, which can then be enforced via Spectral rulesets in CI pipelines. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did Germany's federal API authorization architecture choose FAPI 2.0 over SAML or SPIFFE/SPIRE? FAPI 2.0 was chosen because it already combines the right OAuth extensions into a coherent, vetted profile with a large population of OpenID Foundation certified implementations and a conformance test suite. SAML was rejected for weak machine-to-machine standardization and heavy XML assertions; SPIFFE/SPIRE was rejected because it requires a SPIRE server and trust domain in every operator's cluster, an operational non-starter at federation scale. _Teams weighing OAuth extensions against alternatives like SPIFFE can compare real-world architecture tradeoffs on daily.dev._ ### What is the difference between the normal and high protection tiers in Germany's API authorization profile? The normal protection tier is built on RFC 9700, the IETF Best Current Practice for OAuth 2.0 Security, which already incorporates stable OAuth 2.1 hardening. The high or very high protection tier is derived and extended from FAPI 2.0, with security properties shown by formal analysis to satisfy the FAPI attacker model rather than merely asserted, unlike most private-sector API programs. _Developers tiering API security requirements can track authorization standard decisions like this on daily.dev._ ## Similar posts on daily.dev - [A Playbook for US Agencies: Emulating Germany's API Authorization Approach](https://daily.dev/posts/a-playbook-for-us-agencies-emulating-germany-s-api-authorization-approach-farh4bldr) · API Evangelist · 0 upvotes · 0 comments - [Common FAPI Misconceptions](https://daily.dev/posts/common-fapi-misconceptions-qpx9ntthq) · Auth0 · 1 upvotes · 0 comments - [Germany Built the API Authorization Blueprint the Rest of Government Needs](https://daily.dev/posts/germany-built-the-api-authorization-blueprint-the-rest-of-government-needs-6zyqh6i0w) · API Evangelist · 6 upvotes · 1 comments - [FAPI for Developers: Here Is Your Guide](https://daily.dev/posts/fapi-for-developers-here-is-your-guide-bhasbajlk) · Auth0 · 1 upvotes · 0 comments - [Building Authentication Systems for Global SaaS Applications: Best Practices](https://daily.dev/posts/building-authentication-systems-for-global-saas-applications-best-practices-pja9e0rfm) · Security Boulevard · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#oauth](https://daily.dev/tags/oauth) [View this post on daily.dev](https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Profile, Don't Invent: How Germany Chose OAuth 2.1 and FAPI 2.0","url":"https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb"},"datePublished":"2026-07-21T12:48:40.849Z","dateModified":"2026-09-14T09:16:57.370Z","description":"Germany's federal API authorization blueprint chose OAuth 2.1 and FAPI 2.0 over bespoke solutions, SAML, SPIFFE/SPIRE, Kerberos, and others. The architecture...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e99a177c6b9a0b1e16ae0d7928171b47?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/e99a177c6b9a0b1e16ae0d7928171b47?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"API Evangelist","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"API Evangelist","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/a36244ae67bc4f41a605f780267ecb5f","url":"https://daily.dev/sources/apievangelist"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,oauth","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"API Evangelist","item":"https://daily.dev/sources/apievangelist"},{"@type":"ListItem","position":3,"name":"Profile, Don't Invent: How Germany Chose OAuth 2.1 and FAPI 2.0"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/profile-don-t-invent-how-germany-chose-oauth-2-1-and-fapi-2-0-qoirligjb#faq","mainEntity":[{"@type":"Question","name":"Why did Germany's federal API authorization architecture choose FAPI 2.0 over SAML or SPIFFE/SPIRE?","acceptedAnswer":{"@type":"Answer","text":"FAPI 2.0 was chosen because it already combines the right OAuth extensions into a coherent, vetted profile with a large population of OpenID Foundation certified implementations and a conformance test suite. SAML was rejected for weak machine-to-machine standardization and heavy XML assertions; SPIFFE/SPIRE was rejected because it requires a SPIRE server and trust domain in every operator's cluster, an operational non-starter at federation scale. Teams weighing OAuth extensions against alternatives like SPIFFE can compare real-world architecture tradeoffs on daily.dev."}},{"@type":"Question","name":"What is the difference between the normal and high protection tiers in Germany's API authorization profile?","acceptedAnswer":{"@type":"Answer","text":"The normal protection tier is built on RFC 9700, the IETF Best Current Practice for OAuth 2.0 Security, which already incorporates stable OAuth 2.1 hardening. The high or very high protection tier is derived and extended from FAPI 2.0, with security properties shown by formal analysis to satisfy the FAPI attacker model rather than merely asserted, unlike most private-sector API programs. Developers tiering API security requirements can track authorization standard decisions like this on daily.dev."}}]} ```