The following notes are some ramblings combining what the speakers said and thoughts I had while listening. I took them for future references and decide to publish them because 🤷 why not.

Notes on day 2.

Stands

It’s always fun to see the myriad of OSS projects having a stand at FOSDEM. After coming here a few years I had seen most of them already so I did not spend too much time browsing around. I did make sure that a picked up some stickers off course!

I did learned about privacyidprivacyIDEA “a modular authentication server”. Honestly I am not exactly certain what it is, it’s not an Idp like keycloak but focusses only on MFA. It seems like way to centrally mange (hardware) tokens & keys for organisations.

The radio amateurs had an interesting stand as always and I was reminded that hamcon will take place later this year.

Main track on desktops

Picture actually taken on day 2.

Wayland compositors for fun and profit

Turns out that building a wayland compositor can be fun and apparently easy because of existing rust libraries. Wayland can even work on the small screen of the Turris opeon source router.

KDE at 30: Still looking ahead

🤔 I have always loved the KDE destkop, but I keep switching between KDE & GNOME (at the time of writing I’m on GNOME). Maybe I should consider switching again, and maybe trye NixOS as a desktop distro.

I learned some new things such as that KDE started in Germany and KHTML started as a KDE project and became webkit over time, which is now used a lot by Apple.

KDE hardware: Slimbooks, Steamdeck.

End of 10 campaign: not all old Windows 10 devices need to be thrown away.

Plsame mobile 6: Difficult to install on mobile because of protected hardware. Some new device called Mecha?

Plasma bigscreen is still a thing.

Linux on the Desktop – Why Digital Sovereignty Starts Here

For organisations that we work with/for it’s important to achieve digital sovereignty. To avoid price gauging, to have freedom of choice and decentralization.

Linux Client Management: Foreman, Config management (SaltStack, Ansible, …), GitOps.

OpenDesk: Zendis (German government digital sovereignty agency) office suite. Existing FOSS tools such as Univention for Identity management and Nordeck for video conferencing.

An EU OS?

Securing enterprise linux: antivirus & disabeling USB device access.

🤔 IS ClamAV actually usefull on a linux desktop? Becasue AFAIK it mostly searches for fingerprints of windows viruses.

Challenging to integrate with proprietary software. No fully sovereign solution at the moment.

Immutable OS is nice to have: Secure, easy to manage.

Sovereign IDM, Himmelblau from samba: seamless Azure Entra ID and Intune integration for Linux.

Security Devroom

All your keybaords are belong to us

Van Eck phreaking: signal leakage, live demonstraion on the BBC youtube: BBC tempest, skip the shakespeare part demo of stealing contents of PC monitor.

Tempest: A signal problem

Books: Spy Catcher & The SPY in Moscow station.

Type writer noise can be used to determine text, soundproofiing help the attacker: improving signal to noise ratio.

Skype-Type: Keyboard acoustisc eavesdropping tool during call. Nowdays difficult due too noise filters.

Markus G. Kuhm: Large paper on emissions

Recording of the rest of the talk on DEFFCON.

The invisible key: Securing the new attack vector of OAuth tokens

Hackers don’t break in, they login.

– Corey Nachreiner (probably)

You can’t apply conditional access to tokens. 🤔 Is that not what the Shared signals framework tries to solve?

Five major conserns:

• Longevity of token and forgotten access
• Scope / privilege creep
• Supply chain risk: the domino effect
• Token leakage
• Revocation gaps and off boarding failure, Off boarding a user does not mean off boarding a token.

Common attack vectors such as during the attack on salesforce. By Gangs: Scattered spider, ShinyHunters. Attacks still often involve social engineering.

How to avoid: Audit OAuth Apps, Centralize logs, use canary tokens

Stop granting overprivileged permissions to applications.

Conditional access requires support on the browser? (🤔 not sure what the speaker meant with this).

Use mTLs for certificate bound client credentials flow or DPoP.

IPSIE, which is the OpenID working group tackeling shared signals.

Dynamic Bot Blocking with Web-Server Access-Log Analytics

You don’t have to use cloudflare for bot detection.

Tempest-tech.com

DDOS prectection & Web security

Fingerprinting of user agents: JA3/JA4, p0f, tempest.

Log shipping to clickhouse.

Identity and Access Management Devroom

This room is cursed.

– The video volunteer when entering the room in the morning.

Day two stared of great with a some great presentations in the IAM devroom. I woke up early so I could get a seat on the front row and was happy that I did.

Thomas Darimont giving a presentation on OpenID’s shared signals framework.

An Introduction to the OpenID Shared Signals Framework

SSF tries to normalize the signals to do Continuous Access Evaluation

Use Cases:

1. Real-time Session Revocation
2. Compromsed Account Alert
3. Automated User Deprovisioning

Building blocks: Security Event, Transmitter (System emitting event), Receiver, Stream and subscription on events. Security Event tokens are an IETF RFC

Profiles: Set of use cases and events

• CAEP
  • Based on sessions
  • Evalutaion of access decisions
• RISC
  • disaster mitigation
  • security risks and inicdnets

Delivery methods are push (RFC 8935) or poll (RFC 8936).

There is also an IETF draft for SCIM Events.

htps://caep.dev

Implementation in Keycloak with pull request 43950 Custom login when receiving events. Next step will be transmitter support.

Questions & thoughts 🤔

• Does the CAPE profile make OpenID connect session managment obsolete?
  • Answer: No, different use cases
• For SaaS, how is privacy of the user handled?
• In Keycloak is the logic on how to handle events configurable, if so how?

Nextcloud as Identity Provider? SCIM Client Integration for Multi-Platform Collaboration

Nextcloud X OpenProject

Use scim for automated identity information exchange.

AGPLv3: The only sensible license option for NC apps according to the speaker .

Questions & thoughts 🤔

• Why not use a dedicated IDP?

Now I am a bit confused on what exactly the difference is between the SCIM client and server. I should do a deep div on SCIM.

Keeping applications secure by evolving OAuth 2.0 and OpenID Connect

FAPI 2.0 was published in 2025 targeting more than just banking (e-health, government).

Security assumptions of FAPI 2.0 were well documented.

https://openid.net/specs/fapi-attacker-model-2_0-final.html

Secure your transport layer!

• TLS 1.2+
• Check certificates
• DNSSEC
• Secure ciphers
• HTSTS

OAuth best pratices

• TLS on all endpoints
• No ROPC
• No wildcards in redirct URIs
• Private key JWT client authentication (no public clients)
• Pushed Auth. request (PAR)
• PKCE with S256
• Sender contrained tokesn (mTLS or DPoP)

An API can respond to a API request with a DPoP nonce request. Adding an extra step to an API request, but improving security.

🤔 I wonder if this is always required for DPoP or if the nonce is optional. The RFC says “An authorization server MAY supply a nonce value to be included by the client in DPoP proofs sent.” So I guess it’s optional. See RFC 9449 for details.

Keycloak has builtin client profiles. Which enforces security requirements on clients. Enforced at config and runtime. Rules can be added to a custom profile.

Funny way to convince development teams to keep clients secure: brownouts to speed up the process. Security with a whip!

There is a keycloak conference taking place in Amsterdam in March 2026.

Questions & thoughts 🤔

Error messages in the Keycloak admin UI suck. This could be something that can be improved by the community. If I felt more comfortable with the codebase I could pick it up.

I wonder if the security profiles could be externalised, I have built scripts in the past to validate OAuth client configs against a set of security rules.

Inside ProConnect: Building a Modern Federated Identity Provider for Government Services

ProConnect enables single login for grench government services (public servants, external users)

La Suite numerique a set of open source tools provided by the French Govt.

Demo with one of the best: Visio for vidio confernces.

• User gives email and ProConnect redirect to the correct underlying IDP.
• The designs of the webui’s are alligned.

From FranceConnect to ProConnect

Proconnect has ~40 Idp’s!

SP & Idp Mocks.

http://www.dev-agentconnect.fr/

Identity borkering: Email domain name based routing.

Passkey auht with AMR POP

Identity format for public servants in a professional context.

Testing is free via Espace Parenaires.

Easy install of ProConnect with Docker.

Open Repository on github

Questions & thoughts 🤔

• If ProConnect is a fork of FranceConnect, is the infra / user database / … also forked?
• IF ProConnect acts as an Identity Broker, how does it decide on the Idp to user?
  • Is the user identified first?
    • Yes, map of email domains to Idp.

Privacy and Sovereignty in a Post Quantum Open World

Kings & Serfs, Masers & Slaves. Closed source users are software slaves!

Business people hat the word freedom (Choice, competition)

Sovereignty, not just for data but: Software, Networking, Technology.

Users need to control

One more consideration: Quantum Computing

• (re)encrypt data
• VPN’s -> QPN’s
• Need to move towards MFA

We need a community of trusted people.

• Freedom Software
• RISC-V Architecture
  • Now moved to swiss

We need sovereign cloud that are security first.

Corporta: Secure sentinel

Community cloud: freedombox.org

Tiny server on SBC.

Also supports fediverse.party software for social networks.

MFA: Hardwayre keys: need to use 2. Has to be open design:

• inspectable
• long life

Working with solokeys an open-source FIDO2 security key.

SUSEID - Sovereign IAM at SUSE

How suse has tackled IAM landscape.

Lot’s of mergers: Multiple password providers, add-ons and bridges.

The ride for an average SUSE Employee

• Open Jira: user +pass
• Open conflunece: user +pass
• Open build service: user +pass
• Bugziall: user +pass
• suse costuomer center: different prompt!

Art21 of nis2 Dora art 5,9,10

-> No SaaS for Auth.

Self hosting comes with costs, (ops, dc, …)

Patroni for HA PostgreSQL Garage for obj storage

Authentik IDP

Existing projects: smallstep KanIDM

New projects:

• stepdance: certifiactes
• ldap SEBIN search + bind
• IDM Merge: Idm Aggregator & Dedup

Credentials for Linux: Bringing Passkeys to the Linux desktop

Passkeys are quite complex.

Passkey = FIDO2 discoverable credential

• usernamesless & passwordless

New FIDO2

• Hybrid flow: Passkey on pohne (qr code)
• synced Passkeys

Modern Passkeys

Phones and password managers Default:

• Google Password manager
• iCloud keychain Third party:
• bitwaden
• oss

requires credential provider API

(synced creendials)

Security keys still for entrprise

Linux desktop needs platform api’s.

Inconsistent api: currently apps (browsers) implement UX themselves.

Containerized (flatpak) apps’ don’t have access to hardware api’s (workaround --device=all, enables origin bypass)

Solution: a new Credentials api.

• D-Bus
• support for privileged and unprvilegd clients

New componenents:

• lebwebauthn: CTAP/WebAuthn
• credentialsd

Use of xdg-desktop portals for sandboxed apps.

In libauthn: TPM 2.0 (platform) is planned

Open Cahllenges:

1. Origin scoping: credentials for your origin should only be accessed by that origin.

• How do we determine origin

2. App identity verification?

Prividleged: any origin (browsers) unprvilegd: restricted to specific origin

Cockpit and passwordless login

Cockpit authentication:

• Preferably PAM modules
• SSO, Kerberos, …
• Flatpak app

SSH keys are an example of passwordless but not usable in te browser.

Based on WebAuthn,FIDO2,Passkeys

• ensure origin authenticity
• web domain / hostname / realm differences.
• /.well-known-webauthn
  • Can support multiple origins.

Registering with the “Chromium virtual authenticator enviroment” for testing / demo.

Passkey

• Discoverable
• limited slots
• no username needed, user
• Non-discoverable
  • doesn’t store on hardware

Questions & thoughts 🤔

I should look further into discoverable vs Non-discoverable credentials on passkeys.

Fancy slides! I wonder what was used to create them.

Passwordless authentication mechanisms from the GUI (GDM)

GDM: Login on gnome (Password, Smartcard, Fingerprint)

Gnome shell renders the UI. Runs as GDM user To authenticate GDM calls PAM over private dbus servers.

Improved UX: select auth. method.

New web login with OAuth device code flow.

Fingerprint only on lock screen.

Available in SSSD 2.12.0

Two merge requests for GNOME 50

Future enhancements:

• embedded webview
• PAM conversation through fd
• Move GDM into systemd?

Questions & thoughts 🤔

Someone asked a question on using SPIFFE which is used for workload authentication, I guess they were wondering if it’s possible to let an AI agent authenticate to a Linux machine with a gnome desktop this way?

Reduce attack surface or keep compatibility: lessons of sudo-rs and run0 transition plans

US Govt. mandating secure software

• Zero trust
• Secure software development
• Switch to modern languages

Will take long time to transition (ZTA, Post-Quantum).

How to reduce attack surface?

• run0 aims for a system without SUID
• polkit for AuthZ

Reducing attack surface

Sudo-rs: Switching to Rust

• Memory safety
• Thread safety
• Error handling
• Strong typing

Large scale deployments

FreeIPA can centrally manage sudo rules

Generic rules

• sudo added support for regexes

Polkit action defintions are local XML-based files. Polkit authorziation rules are written in javascript, have to be local files.

sudo-rs: missing features

Questions & thoughts 🤔

Is the goal of sudo-rs to have feature parity with sudo?

I should look into how polkit handles fine grained authorziation.

Rust Devroom & Lightning Lightning Talks

Rust Coreutils in Ubuntu: Yes, we rewrote /bin/true in Rust – Here’s what really happened

Pareto rules: 80 of the work takes 20 of the time

What’s next.

Rewrite other GNU utilities.

Questions & thoughts 🤔

GPL debate: Is canonical just supporting this so they can get rid of GPL code in their distro?

CONTRIBUTING.yaml

CONTRIBUTING.md but machine readable

• status
• intentions
• support needs

ECMA standarization track.

https://www.tc54.org/contributing-yaml/

Misconceptiosn heard at FOSDEM about CRA

• No fines for open source projects.
• You can take donations.
• Your employer won’t be liable if you as an employee work on foss
• Releasing FOSS does not mean that you need to fill in compliance documents.
• an open source steward can be useful, but is not required.
• The CRA does not require changes to project processes
• …

Dumb guide to smart TVs

You pay for:

• ads
• Automatic Content Recognition
• Send low quality screenshots to vendor.
• the netflix button

Nu smart TV allows you to turn off all of the anti-features

• dont’t connect it to the internet
• hack your TV!

body.build

Wikipedia bring the best articles, what is the equivalent for fitness?

1. Database of exercises
2. Applications

• program creator
• calorie calculator
• …

https://body.build/

PostgreSQL compatibility index

Not everyone that claims to be PostgreSQL compatible actually is.

Suite to test compatibility.

pacman cache server

I’m not using Arch at the moment so I took no notes 😄.

EU software patents via UPC

ffii.org

GUI vs TUI – Why not both?

Amazing!

web browser -> wayland -> terminal

Render browser directly to terminal

Not interested in smart but funny. https://github.com/dextero/smithay

Git for email

Using a git repo to represent emails as files.

RCL configuration language

Extends JSON by adding variables functions loops …

Can also be used to query

🤔 I wonder what the difference is with Jsonnet.

Gitify your life - 14 years later

Etckeeper, bup, ikiwiki, git-annex, metamonger, vcsh, mr, zsh.

Main track

Open Source Security in spite of AI

Took no notes.

https://daniel.haxx.se/blog/2026/02/03/open-source-security-in-spite-of-ai/

Closing FOSDEM 2026

If we lose our democracies Open Source is irrelevant and goes away!

– RichiH

Talks I would still like to watch later

There were a whole lot of talks that I was not able to watch. Luckily talks at FOSDEM are recorded & avaiable on video.fosdem.org!

Listed talks.

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.

What is Authorization?

Decide if an action can be taken.

• Can Alice view document #123?
• Can Alice view document #123 at 16:30 on Tuesday, 11 June, 2024?
• Can Bob edit document #123 in China?
• Can Bob edit document #123 in China, when authenticated with MFA?
• Can a manager create document #456

We can always identify the following:

• Subject, the user or thing trying to take an action
  • Type & identifier
    • E.g. user:Alice, application:123
  • Or properties of the subject
    • E.g. manager
• Action, the thing the subject is trying to do
  • E.g. view, edit
• Resource, the target of the action
  • Type & identifier
  • E.g. document:#123
• Context, any additional information that can influence the decision.
  • E.g. time, location, authentication method.

Additionally we often want to search based on the authorization decisions. A search is essentially a decision with one or more free variables.

• Which documents can Alice view?
• Who can view document 123?
• What actions can Alice perform on document 123 on Tuesday, June 11, 2024?

Access control models

Access control models can be separated by their specificity.

Coarse-grained access control models

Role-based access control (RBAC), is the most common access control model. A subject is assigned to a role and depending on their role the application decides whether to allow access.

Coarse grained access control models such as RBAC are easy to implement.

It might look like they are easy to manage but in practice group, entitlements and roles become a mess.

Fine-grained access context models

Often this is implemented by mapping specific actions on resources to entitlements (arbitrary strings) and combining those in a role and assigning those to a group of subjects.

Relationship-based access control (ReBAC) looks at the relation of resources and subjects. Essentially it looks at the graph of resources and subjects to decides whether an action is allowed.

From: https://docs.aserto.com/docs/authorization-basics/authorization-models/rebac

Attribute-based access control (ABAC), compares attributes assigned to a subject and resource to decide if an action is allowed.

Policy-based access control (PBAC), the most generic model. A policy can be any evaluation of any computer program. Often specific domain specific languages are used to describe the policy.

Hybrid models

Coarse-grained and fine-grained can be combined. For example an API gateway or application proxy can check if a user is allowed to access a service using RBAC but the service can use a more fine-grained model such as ReBAC to check if specific actions are allowed on a resource.

This approach can improve performance and provide better (mutli-layered) security.

Google’s Zanzibar

Determining whether online users are authorized to access digital objects is central to preserving privacy. This paper presents the design, implementation, and deployment of Zanzibar, a global system for storing and evaluating access control lists. Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Its authorization decisions respect causal ordering of user actions and thus provide external consistency amid changes to access control lists and object contents. Zanzibar scales to trillions of access control lists and millions of authorization requests per second to support services used by billions of people. It has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use.

https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/

Authorization Policies

These describe the rules. From Nist’s guide to ABAC:

Natural Language Policy (NLP): Statements governing management and access of enterprise objects. NLPs are human expressions that can be translated to machine-enforceable access control policies.

Digital Policy (DP): Access control rules that compile directly into machine executable codes or signals. Subject/object attributes, operations, and environment conditions are the fundamental elements of DP, the building blocks of DP rules, which are enforced by an access control mechanism.

Metapolicy (MP): A policy about policies, or policy for managing policies, such as assignment of priorities and resolution of conflicts between DPs or other MPs.

Digital policies are the real software implementation of the policy. These are often described using A DCL XACML, ALFA, Rego, Oso Polar.

A policy evaluation engine takes the authorization policy, and the authorization request and outputs a decision.

Digital Policy example with Rego

Rego is currently the most popular and open language for to define policies, it was developed for the OPA policy engine and is based on the datalog programming language.

Rego is a declerative programming language, made for writing authorization policies.

The following is an example from the Rego playground.

Policy:

package app.abac

default allow := false

allow if user_is_owner

allow if {
	user_is_employee
	action_is_read
}

allow if {
	user_is_employee
	user_is_senior
	action_is_update
}

allow if {
	user_is_customer
	action_is_read
	not pet_is_adopted
}

user_is_owner if data.user_attributes[input.user].title == "owner"

user_is_employee if data.user_attributes[input.user].title == "employee"

user_is_customer if data.user_attributes[input.user].title == "customer"

user_is_senior if data.user_attributes[input.user].tenure > 8

action_is_read if input.action == "read"

action_is_update if input.action == "update"

pet_is_adopted if data.pet_attributes[input.resource].adopted == true

Data:

{
    "user_attributes": {
        "alice": {
            "tenure": 20,
            "title": "owner"
        }
    },
    "pet_attributes": {
        "dog123": {
            "adopted": true,
            "age": 2,
            "breed": "terrier",
            "name": "toto"
        }
    }
}

Input:

{
    "user": "alice",
    "action": "read",
    "resource": "dog123"
}

Output:

{
    "action_is_read": true,
    "allow": true,
    "pet_is_adopted": true,
    "user_is_owner": true,
    "user_is_senior": true
}

Externalized Authorization Architecture

Often the authorization is implemented in the application itself, either hard-coded or trough configurations. But this approach has shortcomings in large, distributed and dynamic systems.

• Policy (interpretation) consistency
• Reuse of implementations
• Policy administration (version control, deployments)
• More difficult to improve performance

For these reasons it is often decided to externalize authorization out of the application.

The simplest approach to externalize authorization is to centralize it in one system. But there are other patterns possible, more on that later.

Defined in XACML and Nist’s guide to ABAC

By Axiomatics - Axiomatics, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=48397652

XACML Dataflow Diagram, image from OASIS spec.

Policy Decision point components

The PDP is shown as one component in the XACML architecture but we can distinguish multiple subcomponents.

Policy Engine is the component responsible for actually evaluating the policy and making a decision.

PDP Interface or API implements how the PEP can send queries to th PDP. Often based upon HTTP and JSON but gRCP. Every PDP implementation uses a different kind of (often proprietary API). But there is a process ongoing by the OpenID foundation to standerize an interface called AuthZEN.

The data plane is responsible for gathering data form the relevant PIP’s. E.g. user & resource attributes. The data plane can also concern itself with caching and structuring the data in a performant data structure such as a graph for performant policy evaluation.

The data plane can exist completely separate from the PDP (any databse or API can be used). But many implementations choose to tightly couple the PDP and PIP for optimal performance.

A policy control plane is required to distribute updates to policies the PDP’s as soon as they are changed. The control plane is the glue between the PAP and PDP. The control plane can also provide information about the configuration of the data plane, such as the location of the PIP’s.

Fancy Archtiectural patterns

OPAL Architecture, from https://docs.opal.ac/overview/architecture/

• Fully centralized service
• Per-tenant
• Per application
  • As a library
  • Sidecar container

Policy administration (PAP)

Many solutions provide powerful interfaces to manage policies.

Policy creation interface. The digital policy can be written as computer program using any text editor or IDE. But many implementations provide interfaces to make it easy to use for less technical people.

Version control is essential for policy management. Often software VCS such as git ore often used because most operations are already using it. But sometimes authorization services implement their own version control, tightly coupled with the ui of the PAP.

Policy distribution trough the control plane, just like any program the authorization policies require some form of continous deployent, depending on the chosen architecture this can become very complex, requiring deployment to multiple PDP’s without having downtime.

Testing should also be considered, the digital policy is a computer program like any other and there should exist ‘unit’ test to ensure that the policies (and any for changes) behave as expected. Issues in a policy can have huge consequences for the security of the system.

AuthZEN

The OpenID foudnation has identified the need for a standardized interface for authorization, similar to their OpenID connect standard for authentication.

https://openid.github.io/authzen/

AuthZEN is essentially an API specification standardizing the contract between PDP and PEP. It contains two API’s.

• Access Evaluation(s) API
• Search API

Access Evaluation API

Modified example from the AuthZEN draft.

The access evaluation API returns the decision as a boolean, but can also provide some context.

An alternative endpoint is also defined that can evaluate multiple decisions in one request.

Request:

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "document",
    "id": "1"
  },
  "action": {
    "name": "edit"
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

Response:

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "decision": false,
  "context": {
    "reason": "Subject is a viewer of the resource"
  }
}

Search API

Example form the draft.

The search API can search for subjects, actions and resources.

It also specifies pagination which is which is essential for scalability.

Request:

POST /access/v1/search/resource HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  }
}

Response:

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "page": {
    "next_token": "a3M9NDU2O3N6PTI="
  },
  "results": [
    {
      "type": "account",
      "id": "123"
    },
    {
      "type": "account",
      "id": "456"
    }
  ]
}

OAuth Rich Authorization Requests

There also exists an extension to famout OAuth authorization framework to implement FGA.

Ideal for when user interaction (permission) is required before allowing a service to take an action. Or for cross-domain use cases.

From RFC 9396: OAuth 2.0 Rich Authorization Requests:

This specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures.

For example, an authorization request for a credit transfer (designated as “payment initiation” in several open banking initiatives) can be represented using a JSON object like this:

{
   "type": "payment_initiation",
   "locations": [
      "https://example.com/payments"
   ],
   "instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName": "Merchant A",
   "creditorAccount": {
      "bic":"ABCIDEFFXXX",
      "iban": "DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number Merchant"
}

From RFC 9396: Example of an Authorization Request for a Credit Transfer

The new enemy problem

Audit logs

An advantage is centralizing the authorization is that it also become easier to centralize the decision logs. These are very useful for auditing.

Projects and products

Open source with commercial offering

All most all (production ready) open source implementations of FGA are backed by a commercial company providing a product based upon the open-source project.

Open source / Commercial product.

• OPA / Styra enterprise OPA & DAS
• OPAL / Permit.io
• Aserto / Topaz
• spiceDB / AuhtZed
• OpenFGA / Auth0 (Okta) FGA
• Casbin / Casdoor

Proprietary

Several companies also sell fully closed source authorization services.

• Oso Security
• Ping Authorize
• AWS Cedar
• Axiomatics
• Permify
• Cerbos

Sources & further reading

• https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• https://idpro.org/the-state-of-the-union-of-authorization/
• https://www.permit.io/blog/what-is-fine-grained-authorization-fga
• https://openid.net/wg/authzen/
• https://openid.github.io/authzen/
• https://www.feldera.com/blog/fine-grained-authorization
• https://docs.aserto.com/docs/authorization-basics
• https://datatracker.ietf.org/doc/html/rfc9396

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.

What is Authorization?

Decide if an action can be taken.

• Can Alice view document #123?
• Can Alice view document #123 at 16:30 on Tuesday, 11 June, 2024?
• Can Bob edit document #123 in China?
• Can Bob edit document #123 in China, when authenticated with MFA?
• Can a manager create document #456

We can always identify the following:

• Subject, the user or thing trying to take an action
  • Type & identifier
    • E.g. user:Alice, application:123
  • Or properties of the subject
    • E.g. manager
• Action, the thing the subject is trying to do
  • E.g. view, edit
• Resource, the target of the action
  • Type & identifier
  • E.g. document:#123
• Context, any additional information that can influence the decision.
  • E.g. time, location, authentication method.

Additionally we often want to search based on the authorization decisions. A search is essentially a decision with one or more free variables.

• Which documents can Alice view?
• Who can view document 123?
• What actions can Alice perform on document 123 on Tuesday, June 11, 2024?

Access control models

Access control models can be separated by their specificity.

Coarse-grained access control models

Role-based access control (RBAC), is the most common access control model. A subject is assigned to a role and depending on their role the application decides whether to allow access.

Coarse grained access control models such as RBAC are easy to implement.

It might look like they are easy to manage but in practice group, entitlements and roles become a mess.

Fine-grained access context models

Often this is implemented by mapping specific actions on resources to entitlements (arbitrary strings) and combining those in a role and assigning those to a group of subjects.

Relationship-based access control (ReBAC) looks at the relation of resources and subjects. Essentially it looks at the graph of resources and subjects to decides whether an action is allowed.

From: https://docs.aserto.com/docs/authorization-basics/authorization-models/rebac

Attribute-based access control (ABAC), compares attributes assigned to a subject and resource to decide if an action is allowed.

Policy-based access control (PBAC), the most generic model. A policy can be any evaluation of any computer program. Often specific domain specific languages are used to describe the policy.

Hybrid models

Coarse-grained and fine-grained can be combined. For example an API gateway or application proxy can check if a user is allowed to access a service using RBAC but the service can use a more fine-grained model such as ReBAC to check if specific actions are allowed on a resource.

This approach can improve performance and provide better (mutli-layered) security.

Google’s Zanzibar

Determining whether online users are authorized to access digital objects is central to preserving privacy. This paper presents the design, implementation, and deployment of Zanzibar, a global system for storing and evaluating access control lists. Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Its authorization decisions respect causal ordering of user actions and thus provide external consistency amid changes to access control lists and object contents. Zanzibar scales to trillions of access control lists and millions of authorization requests per second to support services used by billions of people. It has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use.

https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/

Authorization Policies

These describe the rules. From Nist’s guide to ABAC:

Natural Language Policy (NLP): Statements governing management and access of enterprise objects. NLPs are human expressions that can be translated to machine-enforceable access control policies.

Digital Policy (DP): Access control rules that compile directly into machine executable codes or signals. Subject/object attributes, operations, and environment conditions are the fundamental elements of DP, the building blocks of DP rules, which are enforced by an access control mechanism.

Metapolicy (MP): A policy about policies, or policy for managing policies, such as assignment of priorities and resolution of conflicts between DPs or other MPs.

Digital policies are the real software implementation of the policy. These are often described using A DCL XACML, ALFA, Rego, Oso Polar.

A policy evaluation engine takes the authorization policy, and the authorization request and outputs a decision.

Digital Policy example with Rego

Rego is currently the most popular and open language for to define policies, it was developed for the OPA policy engine and is based on the datalog programming language.

Rego is a declerative programming language, made for writing authorization policies.

The following is an example from the Rego playground.

Policy:

package app.abac

default allow := false

allow if user_is_owner

allow if {
	user_is_employee
	action_is_read
}

allow if {
	user_is_employee
	user_is_senior
	action_is_update
}

allow if {
	user_is_customer
	action_is_read
	not pet_is_adopted
}

user_is_owner if data.user_attributes[input.user].title == "owner"

user_is_employee if data.user_attributes[input.user].title == "employee"

user_is_customer if data.user_attributes[input.user].title == "customer"

user_is_senior if data.user_attributes[input.user].tenure > 8

action_is_read if input.action == "read"

action_is_update if input.action == "update"

pet_is_adopted if data.pet_attributes[input.resource].adopted == true

Data:

{
    "user_attributes": {
        "alice": {
            "tenure": 20,
            "title": "owner"
        }
    },
    "pet_attributes": {
        "dog123": {
            "adopted": true,
            "age": 2,
            "breed": "terrier",
            "name": "toto"
        }
    }
}

Input:

{
    "user": "alice",
    "action": "read",
    "resource": "dog123"
}

Output:

{
    "action_is_read": true,
    "allow": true,
    "pet_is_adopted": true,
    "user_is_owner": true,
    "user_is_senior": true
}

Externalized Authorization Architecture

Often the authorization is implemented in the application itself, either hard-coded or trough configurations. But this approach has shortcomings in large, distributed and dynamic systems.

• Policy (interpretation) consistency
• Reuse of implementations
• Policy administration (version control, deployments)
• More difficult to improve performance

For these reasons it is often decided to externalize authorization out of the application.

The simplest approach to externalize authorization is to centralize it in one system. But there are other patterns possible, more on that later.

Defined in XACML and Nist’s guide to ABAC

By Axiomatics - Axiomatics, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=48397652

XACML Dataflow Diagram, image from OASIS spec.

Policy Decision point components

The PDP is shown as one component in the XACML architecture but we can distinguish multiple subcomponents.

Policy Engine is the component responsible for actually evaluating the policy and making a decision.

PDP Interface or API implements how the PEP can send queries to th PDP. Often based upon HTTP and JSON but gRCP. Every PDP implementation uses a different kind of (often proprietary API). But there is a process ongoing by the OpenID foundation to standerize an interface called AuthZEN.

The data plane is responsible for gathering data form the relevant PIP’s. E.g. user & resource attributes. The data plane can also concern itself with caching and structuring the data in a performant data structure such as a graph for performant policy evaluation.

The data plane can exist completely separate from the PDP (any databse or API can be used). But many implementations choose to tightly couple the PDP and PIP for optimal performance.

A policy control plane is required to distribute updates to policies the PDP’s as soon as they are changed. The control plane is the glue between the PAP and PDP. The control plane can also provide information about the configuration of the data plane, such as the location of the PIP’s.

Fancy Archtiectural patterns

OPAL Architecture, from https://docs.opal.ac/overview/architecture/

• Fully centralized service
• Per-tenant
• Per application
  • As a library
  • Sidecar container

Policy administration (PAP)

Many solutions provide powerful interfaces to manage policies.

Policy creation interface. The digital policy can be written as computer program using any text editor or IDE. But many implementations provide interfaces to make it easy to use for less technical people.

Version control is essential for policy management. Often software VCS such as git ore often used because most operations are already using it. But sometimes authorization services implement their own version control, tightly coupled with the ui of the PAP.

Policy distribution trough the control plane, just like any program the authorization policies require some form of continous deployent, depending on the chosen architecture this can become very complex, requiring deployment to multiple PDP’s without having downtime.

Testing should also be considered, the digital policy is a computer program like any other and there should exist ‘unit’ test to ensure that the policies (and any for changes) behave as expected. Issues in a policy can have huge consequences for the security of the system.

AuthZEN

The OpenID foudnation has identified the need for a standardized interface for authorization, similar to their OpenID connect standard for authentication.

https://openid.github.io/authzen/

AuthZEN is essentially an API specification standardizing the contract between PDP and PEP. It contains two API’s.

• Access Evaluation(s) API
• Search API

Access Evaluation API

Modified example from the AuthZEN draft.

The access evaluation API returns the decision as a boolean, but can also provide some context.

An alternative endpoint is also defined that can evaluate multiple decisions in one request.

Request:

POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "resource": {
    "type": "document",
    "id": "1"
  },
  "action": {
    "name": "edit"
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}

Response:

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "decision": false,
  "context": {
    "reason": "Subject is a viewer of the resource"
  }
}

Search API

Example form the draft.

The search API can search for subjects, actions and resources.

It also specifies pagination which is which is essential for scalability.

Request:

POST /access/v1/search/resource HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@example.com"
  },
  "action": {
    "name": "can_read"
  },
  "resource": {
    "type": "account"
  }
}

Response:

HTTP/1.1 OK
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "page": {
    "next_token": "a3M9NDU2O3N6PTI="
  },
  "results": [
    {
      "type": "account",
      "id": "123"
    },
    {
      "type": "account",
      "id": "456"
    }
  ]
}

OAuth Rich Authorization Requests

There also exists an extension to famout OAuth authorization framework to implement FGA.

Ideal for when user interaction (permission) is required before allowing a service to take an action. Or for cross-domain use cases.

From RFC 9396: OAuth 2.0 Rich Authorization Requests:

This specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures.

For example, an authorization request for a credit transfer (designated as “payment initiation” in several open banking initiatives) can be represented using a JSON object like this:

{
   "type": "payment_initiation",
   "locations": [
      "https://example.com/payments"
   ],
   "instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName": "Merchant A",
   "creditorAccount": {
      "bic":"ABCIDEFFXXX",
      "iban": "DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number Merchant"
}

From RFC 9396: Example of an Authorization Request for a Credit Transfer

The new enemy problem

Audit logs

An advantage is centralizing the authorization is that it also become easier to centralize the decision logs. These are very useful for auditing.

Projects and products

Open source with commercial offering

All most all (production ready) open source implementations of FGA are backed by a commercial company providing a product based upon the open-source project.

Open source / Commercial product.

• OPA / Styra enterprise OPA & DAS
• OPAL / Permit.io
• Aserto / Topaz
• spiceDB / AuhtZed
• OpenFGA / Auth0 (Okta) FGA
• Casbin / Casdoor

Proprietary

Several companies also sell fully closed source authorization services.

• Oso Security
• Ping Authorize
• AWS Cedar
• Axiomatics
• Permify
• Cerbos

Sources & further reading

• https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• https://idpro.org/the-state-of-the-union-of-authorization/
• https://www.permit.io/blog/what-is-fine-grained-authorization-fga
• https://openid.net/wg/authzen/
• https://openid.github.io/authzen/
• https://www.feldera.com/blog/fine-grained-authorization
• https://docs.aserto.com/docs/authorization-basics
• https://datatracker.ietf.org/doc/html/rfc9396

Multi-factor authentication (MFA) is a security process that requires users to verify their identity using two or more distinct factors. Each factor can be from one of the following categories:

• Something you know (e.g., a password)
• Something you have (e.g., a security token or mobile device)
• Something you are (e.g., a biometric such as fingerprint or face recognition)

For an authentication method to be secure, it should validate at least two factors.

Business Value

Multi-factor authentication (MFA) delivers critical business value by significantly strengthening security and reducing the risk of data breaches, phishing, and credential theft, even if passwords are compromised. This protection safeguards not only sensitive company and customer data but also preserves customer trust and brand reputation, which are invaluable assets in today’s digital economy. As remote and flexible work becomes standard, MFA ensures secure access to company systems from any location, enabling productivity without sacrificing security. Beyond risk reduction, MFA also drives cost savings by minimizing fraud, security incidents, and IT support overhead, while integrating seamlessly with existing identity management systems to streamline operations and enhance efficiency. In essence, MFA is a strategic investment that secures assets, supports modern work environments, and protects your bottom line.

Authentication methods

Why multiple options

Offering multiple MFA methods directly addresses both user experience and operational resilience. Users have different preferences and access to devices. Some may prefer the convenience of an authenticator app, while others rely on SMS or biometrics. By providing choices, you reduce friction and increase adoption rates, which is critical for widespread security compliance. At the same time, redundancy ensures that if a user loses access to one method (like a misplaced phone), they aren’t locked out of their account and can fall back on an alternative, such as email verification or a hardware token. This not only keeps productivity high but also aligns with industry best practices and regulatory requirements, helping your product meet security standards without sacrificing usability. In short, it’s about balancing strong security with a seamless experience, which ultimately builds trust and reduces support overhead. idpro-mfa-for-humans

Passkey (WebAuthn / FIDO2)

|———-|————————————-| | Factors | - Something you have (device) | | | - Somehting you know (PIN) |

Passkeys are a modern, user-friendly, and phishing-resistant authentication method designed to replace passwords entirely. Built on WebAuthn and FIDO2 standards, passkeys enable passwordless and usernameless logins, relying instead on cryptographic keys stored on the user’s device (e.g., smartphone, laptop, or security key). They simplify the user experience by eliminating the need to remember or enter credentials, while also providing stronger security than traditional passwords.

The AAGUID (Authenticator Attestation GUID) identifies the passkey provider, use this to display a user-friendly name (e.g., “iPhone Passkey” for better clarity and management.

Synced passkeys are stored encrypted in the cloud and automatically synchronized across a user’s registered devices, such as through iCloud Keychain or Google Password Manager. This allows users to log in passwordlessly from any of their trusted devices, offering convenience and flexibility.

Essentially passkeys act like a direct interface between the server and the password manager.

Device-bound passkeys are permanently tied to a single device, such as a smartphone, laptop, or hardware security key. They cannot be exported or synced, providing stronger security by ensuring the private key never leaves the device.

Hardware security keys could be provisioned and distributed amongst the users. But this can be expense and time consuming. Most often companies choose to let the user provision their own security key, then it can also be used to access multiple services.

The most known hardware security key is the yubikey, but sold by many vendor such as OneSpan.

TOTP

|———-|———————————–|

TOTP (Time-based One-Time Passcode) is a temporary, time-sensitive passcode generated by an algorithm using the current time and a shared secret key. Each code is valid only for a short period (usually 30 seconds), adding an extra layer of security for authentication.

OATH (Initiative for Open Authentication) is an industry standard that defines protocols for TOTP. It ensures compatibility and interoperability between servers and authenticator apps. It is supported by all authenticator apps such as:

• Aegis Authenticator
• Google Authenticator
• Microsoft Authenticator

To set up TOTP, users scan a QR code with their authenticator app and enter the generated code to confirm it works. On mobile devices, since scanning a QR code displayed on the same screen isn’t practical, use an otpauth:// URL to directly open and configure the authenticator app.

The authentication server should implement an OTP window, a setting to account for clock synchronization differences. This improves user experience by accepting codes generated in the previous, current, and next time intervals. This flexibility accounts for minor clock differences between the server and user device, reducing failed logins.

SMS OTP (One time passcode)

|———-|———————————————-|

SMS OTP (One-Time Password) is a widely used multi-factor authentication method where a temporary, numeric code is sent to a user’s mobile phone via text message after they enter their username and password. This code, typically 4–6 digits long, is valid for a short period (often a few minutes) and must be entered into the login prompt to complete authentication.

Attackers may perform SIM swaps to intercept SMS-based OTP codes.

Email OTP

|———-|———————————————-|

Email OTP sends a one-time code to the user’s inbox for login verification. If self service password reset is enabled, email OTP results in only one factor.

Magic links a passwordless authentication method that sends users an URL, allowing them to log in securely by clicking the link instead of entering the OTP code. Consider using this to improve user experience in combination with the OTP code.

Mobile App Push notifications

|———-|————————————————|

Mobile App Push Notifications authenticate users by sending an approval push notification to a smartphone app. This method is user-friendly, as it only requires a tap to approve or deny login attempts. It also encourages app adoption.

Attackers can use MFA fatigue attacks exploit push notifications by overwhelming users with repeated authentication prompts until they accidentally approve one.

Backup security codes

|———-|————————————————–|

Backup Security Codes are single-use, one-time passcodes (OTPs) provided as a last-resort authentication method when other MFA options are unavailable. They should be displayed only once, never sent via email, and users should be allowed to regenerate them if needed. It’s best to notify users (via email or SMS) whenever a backup code is used. However, these codes should be avoided if alternative MFA methods are available, as users often do not store them securely.

External Authentication

External authentication delegates user verification to a trusted third-party service or identity provider (Idp).

Itsme

Belgian eID

|———-|————————————-| | Factors | - Something you have (eID card) |

Authentication with Belgian eID cards is a secure method exclusively for Belgian citizens, using their national electronic identity card. It requires a card reader and the user’s PIN code, though many users forget or don’t know their PIN. Web authentication relies on mutual TLS (mTLS), ensuring encrypted communication between the card and the server. Organizations must maintain the PKI infrastructure, including government-issued CA certificates and support for evolving cryptographic schemes, to ensure compatibility and security.

Federation with the company Idp

|———-|———————-|

Federation with a client’s company Identity Provider (IdP), such as Microsoft Entra ID, allows users to authenticate directly through their organization’s system. This setup enables Single Sign-On (SSO), making it user-friendly by letting employees log in with their corporate credentials. Federation is typically based on the user’s email domain, automatically redirecting them to their company’s login portal. In OpenID Connect (OIDC), you can use the acr_values parameter to request specific authentication assurance levels. A direct link specific for the company should also be created so it can be shown on the company’s webportal.

Federation with de facto standard and social Idp’s

|———-|———————-|

Federation with de facto standard and social IdPs (like GitHub, Google, Microsoft, Facebook, or LinkedIn) lets users log in to your service using their existing social or professional accounts.

Considerations when implementing MFA

Temporarily trust a device for a set number of days to skip MFA prompts.

• Trusted Browsers: Use a secure cookie to maintain trust.
• Mobile Apps: Store an OIDC refresh token securely, avoiding indefinite reuse.
• Desktop Apps: Trust mechanisms vary by implementation.

Registration

If MFA is mandatory, provide a simple, step-by-step setup wizard to guide users through the configuration process.

Managing MFA methods

Enable users to manage their authentication methods through self service. They should be able to view their recent logins, including location, IP, and method used, as well as see when each authentication method was created and last used, for example, “Passkey (Windows): Created on 2025-10-13 00:11, last used on 2025-10-13 00:11.”

Allow users to add, reset, or remove authentication methods, and ensure they can clearly see which account they are modifying by displaying their username, email, and other account information. Before permitting any changes, verify the user’s identity with a high level of assurance.

Support the creation of multiple authentication methods of the same type, such as several authenticator apps or passkeys, to provide flexibility and backup options.

Password reset

Don’t forget to aks for a second factor after letting the user reset their password. This prevents malicious actors from gaining access to an account by doing a password reset.

Helpdesk support

Allow helpdesk to help a user get access to their account. But avoid social engineering attacks. Make sure that the user is thoroughly identified by the helpdesk.

Audit logging

Robust MFA audit logging is essential. Track when users add or use an authentication method, capturing key details like time, device, IP, location, and method type. This visibility helps detect anomalies, supports compliance, and enables quick incident response.

Consider setup up authentication

To improve user experience we don’t have to ask the user to authenticate with multiple factors during their initial login. We can provide limit access to the application with an easy to use method such as a simple password, magic link or trusted device. But only show less sensitive data and allow limited actions. If the user want’s to take sensitive actions, we can increase or ‘set up’ our assurance level by requesting that the user authenticates using a second factor.

Ideally the fine grained authorization policy engine can handle policies where a certain assurance level is required. In OIDC the amr and acr claims can be used to check te assurance level.

Rollout

A phased rollout of multi-factor authentication (MFA) ensures a smoother, more effective implementation by allowing users to adapt gradually, reducing the risk of disruptions, and giving your IT and support teams the bandwidth to address issues as they arise. Starting with high-priority systems or user groups lets you focus resources where they’re needed most, while gathering feedback at each stage helps refine the process before wider adoption. This approach not only minimizes operational risks and user resistance but also ensures that security improvements are sustainable and aligned with both business needs and user experience. Ultimately, it’s about achieving strong security without compromising productivity or overwhelming your teams.

Prepartion

When preparing for an MFA rollout, it is important to:

Ensure each user has only one account to avoid confusion or duplication. Verify that user contact details, such as phone numbers and email addresses, are accurate and up to date. Confirm that your Identity and Access Management (IAM) system fully supports the authentication methods you plan to implement.

Phase 0: Enable MFA

Phase 1: Focus group

Learn lessons to improve user experience.

Phase 2a: Recommend MFA for critical accounts

Phase 2b: Enforce MFA for critical accounts

Phase 3a: Recommend MFA for everyone ## Phase 3b: Enforce MFA for everyone

Non-human account access delegation

Allow services to access API’s on the users behalf using a dedicated API security mechanism, preferably [[OAuth]]. Often people want to use automations, the non-human service should not use the users credentials.

Sources

https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html https://www.cyber.gc.ca/en/guidance/steps-effectively-deploying-multi-factor-authentication-mfa-itsap00105

Let’s first describe some principles that should in order of importance.

1. Pragmatic Security

When creating an API the primary goal is to solve a problem for a user or organisation. But we don’t want to create new problems by introducing vulnerabilities.

When designing or implementing a new feature always consider how it could be abused and strive for security by design.

Be pragmatic, solve problems don’t create new ones.

2. Use Standards & Frameworks

When it comes to security, many organisations face the same problems, luckily as a result we can also use the same solutions. In the world of software engineering we are blessed with great open standards organisations and communities such as OWASP, IETF, the OpenID Foundation, and the many open source communities.

When faced with a check if one of the tools you are using might already have a solution or look online if there are no current best practices on how it can be solved.

For example, the front-end framework you are using probably has a way to obtain OAuth tokens, and don’t implement JWT validation yourself, your API framework or standard library probably has an implementation of JOSE already.

But be ware of the third-party risk, don’t just add any random library as a dependency.

Using standards and frameworks ensures interoperability, not only internally but also when working with vendors, partners and customers. It also ensures that we use reviewed solutions and implementations.

3. Layered Security

• ZTA
• …

Guidelines

Threat Model

The first step when considering security for any project is to start with a threat model. Don’t know what threat modeling is? Take a look at the Threat Modeling Manifesto which gives the following definition.

Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.

The manifesto describes four questions to ask to start threat modeling.

1. What are we working on? (Create a model)
2. What can go wrong? (Identify threats)
3. What are we going to do about it? (Design & implement mitigations)
4. Did we do a good enough job? (Review & repeat)

Plenty has been written online about threat modeling, so there is no need to explain it further in this note. But I would like to highlight the following.

Threat modeling as a team activity, not a CISO requirement

Threat modeling should be an activity practiced by the team designing and implementing the system. It’s a fundamental way of doing pragmatic security by focussing on mitigating the threats that really matter.

Creating and discussing the potential threats your system faces is a great way to get the team to think about security and have security by design.

Unfortunately a threat model is often seen as a requirement form the CISO-office which might require a DFD-diagram and threat categorized with STRIDE so they can check the checkbox on their compliance spreadsheet without really caring about security. Threat modeling without involving the team is a waste of time.

Model your way

Data-flow-diagrams DFD’s and STRIDE can be great tools, but if you already have other models of your system you should not have to create a new digram form scratch.

Continuous Threat Modeling

When adding a new endpoint or making changes to an existing one, make sure to update your threat model. Threat modeling is a continuous activity and not a one off.

Further reading

• Threat Modeling - OWASP Cheat Sheet Series
• Threat Modeling Manifesto

Pentest

Internet facing API’s should always be pentested.

Monitoring & Logging

Ideally a security operations center (SOC)

Secure your transport layer!

• TLS 1.2+
• Check certificates
• DNSSEC
• Secure ciphers
  • https://ciphersuite.info
• HTSTS

References

• OWASP API Security Top 10 [1]: OWASP Application Security Verification Standard (ASVS) | OWASP Foundation
• REST Security - OWASP Cheat Sheet Series
• Threat Modeling - OWASP Cheat Sheet Series

But in many real world architecture this pattern is difficult to apply. Let’s look the following simple example. We want to built an application that shows a simple list of all documents a user has access to.

We could retrieve all documents from the datastore and ask the PDP whether our user has access and only return those. But that has an obvious disadvantage.

The people over at OpenID AuthZen have proposed to a search API. Where instead of searching in our datastore, we search in the PDP directly. Unfortunately this approach makes it difficult or at least impractical to implement filters by the applications such as search by document name.

In this case the PDP would also be responsible for pagination which may not be preferred. Additionally the PDP would have to know about each resource and their relevant attributes. In reality this is something stored in the datastore.

What we really need in practice are policy-based data filters. Where we ask the PDP for a filter under which condition the user is allowed to access a resource. We can then combine this authorization filter with any filer need by the application logic to query the datastore.

Example worked out in

[[opa_data_filter]]

AuthZen Data Filter API draft

https://hackmd.io/@oidf-wg-authzen/HkLiZVdb1l