Confusion about Okta's offerings

[k_sze]

I’m reading the docs at https://developer.okta.com and I’m quite confused about Okta’s offerings. I can’t conjure a coherent picture of what Okta does.

Here are some specific points that I hope someone can clarify, confirm, or correct for me:

1. Basically, Okta offers three auth mechanisms: OAuth 2.0+OpenID Connect, OpenID Connect only, and finally SAML(2);
2. OAuth 2.0+OpenID Connect and SAML are equivalent in functionality, both do authorization (proving who you are and carry access/permission information), but the authorization workflow (and probably the API endpoint URLs) are different; whereas OpenID Connect would be authentication only (just proving who you are).
3. An OpenID Connect token does not carry any access/permission information. However, my service backend could still figure out the access/permission granted to the user in some other way (maybe I have a table that maps user IDs to permissions in my own database).
4. An OAuth 2.0 token would carry access/permission information, but I guess it’s best used for coarse grained access control? It’s like the OAuth 2.0 token would determine what functions a user or an app can call, and my service backend can further limit what arguments the user or app can call the functions with (or what resources the user or app can affect or retrieve using the functions), correct?
5. Conceptually, if I use OAuth 2.0, what am I protecting against what? Am I protecting my user from client apps? Am I protecting my service backend against the user? Or am I protecting my service backend against the client app?
6. “API Access Management” is just (an implementation of) OAuth 2.0?

[Govner]

1. OIDC is an authentication later built upon OAuth 2.0 Framework which was developed for authorization
2. The difference in implementation for OAuth 2.0/OIDC via Okta is a JWT access/id token instead of the XML assertion format that SAML and both can contain authorization claims uses.OIDC also offers some additional functionality such as the online introspection endpoint for token validation and the userinfo endpoint for expanded user context information
3. Okta does allow you to map attributes to claims in the ID token but its best practise to place these in the OAuth 2.0 access token
4. You can use any combination of scopes and claims to make fine grained or coarse grained authorization decisions in your application
5. This depends on the flow type you use, OAuth 2.0 was developed to allow users to give permissions to a client application to consume a resource server (for instance a 3rd party API) on behalf of the user via consent. However if you use client credentials flow you are making a service to service call with no user context
6. Yes