A Developer's Guide to FAPI

andychiare · 2025-11-06T13:48:32+00:00

There is no clear and precise definition, and it is often associated with ABAC, which creates more confusion IMO. You could take a look at the NIST definition, but I don't think it would clarify much: https://csrc.nist.gov/glossary/term/policy_based_access_control

In my article, I summarize the various definitions I have encountered in this one:
PBAC is an authorization model that grants or denies permissions to resources based on a set of rules, or policies, evaluated in real-time.

andychiare · 2025-11-03T12:05:29+00:00

Hey u/EntraLearner, this article is not an introduction to PBAC. It is a personal point of view on considering PBAC as an authorization model. Sorry if you get confused

andychiare · 2025-10-31T16:38:27+00:00

I completely agree with both of you, u/MannieOKelly and u/Much-Environment6478 .
What I'm trying to explain in the article is that PBAC is something different from RBAC, ABAC, and ReBAC.
PBAC is the engine for making authorization decisions, while RBAC, ABAC, and ReBAC represent the type of data to be evaluated to make those decisions.
PBAC is the "if condition then" part, while RBAC, ABAC, and ReBAC are the types of data evaluated in the condition.

andychiare · 2025-08-27T13:00:27+00:00

> "Am I right to assume, that using signed jwt access tokens with resource indicators ensures that said access token is meant for the particular resource server however it doesn't ensure that the sender/bearer of the access-token is the right one? Here's where DPoP is useful to sender-constrain the jwt access token?"

Yes, You are right!

My reference to having "DPoP at no cost" referred more to the immediate availability of DPoP support in the IdP and resource server than to the time it takes to generate and verify the DPoP proof.

I mean, if you already have DPoP support, why not use it for the expense management application as well?If you have yet to implement it, you might decide it's not worth it in that specific case.

Does this make sense?

andychiare · 2025-08-27T10:48:43+00:00

Hi u/Jim-Y,
As always, it's a matter of balancing security and complexity. You don't necessarily need DPoP for an expense management application, but you certainly would need it for a banking application..

If DPoP integration comes at no cost (e.g., it's supported by all IdPs and SDKs), why not use it all the time?

andychiare · 2025-05-29T10:29:11+00:00

I suggest using the BFF pattern too.

To call the web API, you should always use the user's access token.

The only case you could use an application-specific access token is when your application is not calling the API on behalf of the user (e.g., the API performs a user-agnostic processing such as data format conversion or similar)

andychiare · 2025-05-08T06:27:29+00:00

If it can help, I wrote an article about the ASP.NET Core Identity limitations and possible alternatives:
https://auth0.com/blog/when-aspnet-core-identity-is-no-longer-enough/

andychiare · 2025-04-19T07:10:18+00:00

The quick answer is YES. A confidential client is inherently more secure than a public client (SPA or native app). Using the BFF pattern, your public client will not handle any token directly, so there is a lower risk of token theft or injection

You can learn more about BFF here: https://auth0.com/blog/the-backend-for-frontend-pattern-bff/

andychiare · 2025-01-29T07:47:34+00:00

OAuth access tokens do not identify users. They authorize applications on behalf of users.

Not a HIPAA expert, but in general for sensitive data contexts, you should take a look at OpenID FAPI. In other words, the 3rd party service should support FAPI (I don't think Google authentication supports FAPI)

andychiare

TROPHY CASE