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

Main track

• Free as in Burned Out: Who Really Pays for Open Source?
• FOSS in times of war, scarcity and (adversarial) AI

DEFCON 33

• All your keyboards are belong to us!

Cosic PQCSA Workshop Brussels 2026

https://www.youtube.com/watch?v=fLcyN2SM1Tk

NDC Copenhagen 2025

• (Azure) Modern Architecture 101 for New Engineers & Forgetful Experts - Jerry Nixon - NDC Copenhagen 2025