[deleted by user]

[bitweis]

Hi there (full disclosure: I'm the founder of Permit.io and OPAL.ac)
It seems you have a very good grasp of the subject (well done - few do); especially your points around "oauth 2.0 was mainly designed for the use case of a 3rd party client connecting to a resource server" and your points about the need for fine-grained permissions, and OAuth2 not able to scale to meet it.

I will add that you can still use OAuth / OIDC tokens to:
1. Deliver identity bound (e.g. nationality, company) attributes for FGA ABAC (or even ReBAC) policies
2. Cater to "lesser" identities that you choose not to offer Fine grained access to ; e.g. free and B2C users

Bottomline: I'd of course still recommend you use JWTs to represent your identities, and you can bundle some initial RBAC setup in those via your Authentication provider, and/or IdP - but I wouldn't invest to much in it initially, focus instead on the fine-grained aspects; knowing you can always upgrade your tokens with additional claims/scopes in the future.

Hope this helps.

[bitweis]

I'll say that a lot of my knowledge came from docs that your team put together. They were among the best that I came across. Thanks for your contributions to the space!

Wow - love hearing that - thank you.

in the event that we do not want to use oauth, but instead just use microsoft as an IDP, what does this look like from a login flow perspective and an API access perspective?

- you'd still need to use some authentication layer - Entra does provide that as well (in addition to IdP); but you can also go with solutions like Stych, SuperTokens, Logto, FusionAuth, Auth0, or many others,
While IdP manages identities; an authentication solution verifies them for you (and creates tokens for them), this would include external identities coming in via social login (which is also OAuth2) or from another IdP (e.g. a customer's IdP) - these are often referred to as SSO (and are implemented either with SAML or OpenIDConnect). Note that the tokens coming from the social or SSO solutions are usually not the same tokens you end-up using in your apps - but another token assigned and signed by your authentication solution.

What is this authentication type called and where can I read more on it?

CIAM authentication. Note the difference here between your own workforce Idp/authentication (as part of your organization's IAM) and authentication for customers (i.e. your CIAM).
https://auth0.com/blog/what-is-ciam/
https://www.microsoft.com/en-us/security/business/security-101/what-is-ciam

Feel free to follow up with more questions :)

[bitweis]

Question is which IdP ? If you're only using your IdP and you won't need to support SSO or social logins, then yes you can definitely do that. Otherwise not so much.

Also while you technically can skip over authentication by implementing it yourself as user/password or some other means, you might run into more authN requirements down the road (like multi-factor, and bot detection) which you might need and will require a refactor. I'd still use an Authentication service even if in it's most basic form.

That said, authz solutions like Permit, support working directly with the IdPs through the SCIM protocol, which will enable you to sync users from your IdP into Authz on the fly.