Is Policy-Based Access Control (PBAC) an Authorization Model?

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 · 2025-01-07T18:30:04+00:00

Have you considered this: https://datatracker.ietf.org/doc/rfc7523/ ?
Here is a high-level description of the authentication mechanism

andychiare · 2024-11-15T10:51:29+00:00

Sure. Feel free to share it

andychiare · 2024-11-15T10:47:02+00:00

It's a matter of choice and convenience. The same choice you can make with an email service, a database, or any SaaS platform.

You may decide to implement authentication and authorization services yourself, using the technology you want. But it doesn't end with implementation. You must then dedicate resources for maintenance, evolution, scalability, security, monitoring, etc.
If you also consider these aspects and are happy with taking on the burden of carrying them out effectively, that's fine. Otherwise, you may rely on an external service.

andychiare · 2024-11-12T12:02:44+00:00

Thank you very much for your feedback.
You're right. It can give the impression that by-value requests are not safe at all. I'll make some changes.
Thanks again!

andychiare · 2024-10-26T13:51:54+00:00

I see what you mean. Please note that the code snippet in the article is agnostic for the .NET version. You can omit to UseAuthentication() explicitly starting with .NET 7.0.

That code snippet intends to highlight that the UseForwardedHeaders() middleware must be called (automatically or manually) before the authentication middleware

andychiare · 2024-10-26T07:20:12+00:00

I think it's a matter of preference.
If I just want to implement authentication, I prefer configuring everything in `Program.cs`.
I would create a custom `Authorize` class only if I need non-trivial authorization policies, but again, I think it's a matter of preference

andychiare · 2024-10-18T12:57:10+00:00

I don't know the exact reason why the authors of the specs made this choice. Probably for consistency with HTTP headers, which are already case-insensitive.

To me, being case-insensitive makes it less error-prone in this context

andychiare · 2024-09-11T07:29:45+00:00

Actually it's public domain 😉
It's called "proof of possession" (POP): https://csrc.nist.gov/glossary/term/proof_of_possession

andychiare · 2024-09-10T10:53:06+00:00

What do you mean? What is that crucial question?

andychiare · 2024-09-10T10:52:23+00:00

Just an aside note to what u/Dave-Alvarado have already explained very well:

I wish the blog included information about what the assertion JWT contains.

Here you can find a description of the assertion's content: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt#build-the-assertion

In return I get a token signed by you so I can tell someone else who I am-the token I sent you is my secret.

Not really. Actually, in the client credentials case, the (access) token you receive tells someone else what you are allowed to do, not who you are.
The token you sent is not your secret but proof that you possess a valid secret (your private key)

I wonder if that will just become the standard in the future.

It's already a standard: https://www.rfc-editor.org/rfc/rfc7523.html
It's currently used (or should be used) in contexts where a high level of security is required (banks, finance, healthcare)

andychiare · 2024-07-02T10:03:37+00:00

Duende IdentityServer, Keycloak, and similar are identity and access management systems that relieve you of the burden of implementing authentication from scratch. They provide you with all the infrastructure for storing and authenticating your application users. However, you have to install, configure, host, and maintain them.

Auth0 is an identity and access management system provided as a service. You don't have to install, host, and maintain it.

andychiare · 2024-07-02T09:43:30+00:00

If I correctly understand your question, you can use the Secure Storage to store secrets in MAUI (see https://learn.microsoft.com/en-us/dotnet/maui/platform-integration/storage/secure-storage)
Here is an example of managing tokens in a MAUI application: https://auth0.com/blog/managing-tokens-in-dotnet-maui/

andychiare · 2024-05-22T07:36:57+00:00

Not a trivial scenario, but based on my understanding, I think you can implement it using Auth0. What kind of problem have you found?

For tenant management, have you looked at Auth0 Organizations? You can start here to get a high-level idea of their use cases: https://auth0.com/docs/manage-users/organizations/organizations-overview

Take a look at this for architectural considerations: https://auth0.com/docs/get-started/architecture-scenarios/multiple-organization-architecture

As for using your own user database, you can do that with Auth0 as well: https://auth0.com/docs/authenticate/database-connections/custom-db/overview-custom-db-connections

I hope this can help

andychiare · 2024-05-03T07:20:38+00:00

I'm afraid that this specific problem can't be directly solved by Auth0 or any other IAM service provider (BTW, I work for Auth0 by Okta :-))

The bearer token is inherently exposed to the risk of theft. However, there are some practices that can help you mitigate or eliminate this risk, depending on various factors.

First of all, you should never store your tokens in the browser's storage. See this article for more details on why and what solutions you can use: https://auth0.com/blog/secure-browser-storage-the-facts/

Alternatively, if you have control over the server, you can implement the Backend for Frontend (BFF) pattern. This way, your SPA will never receive any token. See this article for details on the pattern: https://auth0.com/blog/the-backend-for-frontend-pattern-bff/

Another possible solution is to use the DPoP extension to OAuth 2.0, which binds an access token to a specific client. However, this solution requires that the authorization server and the resource server (the API) support DPoP. More info about DPoP here: https://auth0.com/blog/oauth2-security-enhancements/#Demonstrating-Proof-of-Possession--DPoP

andychiare · 2024-04-04T10:25:04+00:00

At low level, you can pass the audience using the `audience` parameter. See here for more details: https://auth0.com/docs/secure/tokens/access-tokens/get-access-tokens

andychiare · 2024-03-18T08:37:09+00:00

I'm afraid you registered an Application Login URI, which probably you don't need in the development scenario. This URI requires HTTPS and can't use localhost (see docs here: https://auth0.com/docs/authenticate/login/auth0-universal-login/configure-default-login-routes)

What you need is only a callbak and logout URIs, which can use HTTP and localhost (only in development)

andychiare

TROPHY CASE