Yes, it would be nice for Okta to supply a working fine-grained access control implementation. However, I wouldn’t hold my breath for it. The basic issue here is that there are two general purpose access control frameworks in place.
In the ABAC architecture, the PDP uses the security context to determine if the operation on the specific resource. In some implementations, this is performed by returning a ‘promise’: essentially an additional ‘where’ criteria to append to the SQL statement the application is about to execute. In your example, if the user has the ability to edit ANY playlist, the PDP would allow access with a ‘promise’ of something like, “playlist_owner = current-user-id”. In other impls, the PDP would query PLAYLIST_OWNER table directly. In either case, a ‘general’ OAuth scope of edit:playlist would suffice.
As a framework, OAuth does allow for fine-grained access control as long as the authorization server supports it. Okta’s supplied authorization server implementation will never natively implement this, as it would require a query into the application’s database as well as application specific logic. Thus, you would need to write your own auth server that understands resource instance specific scopes (edit:playlist:1737428373) and use that. This would allow the PDP to only need to see if the appropriate scope was present in the access token to grant/deny the operation.
While you could create a set of scopes for each resource instance (playlist) within an Okta auth server, I would hesitate to do so, as you also need to have an appropriate access control policy defined. To me, keeping this all in sync between an application an Okta would be a challenge operationally.