Hey, it was my understanding that the Core Authorization Library and the Authorization Extension library were separate, but it seems like you need to use both from this article
If that’s the case, then based on this thread, built in authorization is only available for Developer Pro accounts?
In general the Authorization documentation is pretty confusing
Thanks for quick replay @kim.maida. When you say available to all customers and free for enterprise, could you point me to where it indicates how pricing will be handled?
@swilks There is no pricing involved. It is free for all users with an Auth0 account, including users with free accounts. I apologize if the way I worded that was strange and unclear! I meant, every tier of account gets the feature, including all accounts ranging from free, dev, dev pro, all the way up to enterprise. It was definitely confusing the way I phrased it, I hope this helps to clarify!
Just out of curiousity, if we needed to implement a different auth paradigm from RBAC (ABAC, for example), would it be possible to plug our own Auth api into Auth0? I was thinking about creating custom rules that include an API call. Is that a common design strategy? Anything else you would recommend?
This is pretty much how you’d do it. Users of the Authorization Extension are already used to this: the extension generates a rule in your Auth0 tenant that makes an API call to the extension every time a user logs in to get the groups, roles and permissions for that user.
Hey @kim.maida, wanted to follow this up and ask about using APIs in general. Whenever I try and create a new API it automatically creates a “machine to machine” application, which are practically not available until you sign up for the developer-pro account. It doesn’t seem like there’s another way to use the RBAC features?
@swilks RBAC is associated with a custom API, but access tokens issued to custom API’s can be issued as part of end-user authentication flows or client credentials so client credentials and in particular the fact that client credentials require a developer pro subscription should not constrain the possibility to use the RBAC feature set as the end-user authentication flows where this would be applicable can be used across all subscriptions.
The flow would be something like:
end-user accesses application.
application initiated an authentication request and also specifies to the Auth0 tenant that it requires an access token for a custom API.
end-user authenticates and provides consent if applicable.
the RBAC feature set if enabled is taken in consideration during the process to issue the access token.
an authentication response (tokens) is delivered to the application.
application makes use of those tokens.
In the above flow client credentials were never required and in addition, even though client credentials are limited to some subscriptions every subscription type will be able to do some tests with it, hence the automatic generation of the machine to machine application. As long as the usage of client credentials is below a reasonable threshold you won’t get any notifications (I think at this time, a few hundred client credentials call per month will be allowed as part of trying the functionality).
My confusion came from the Machine to Machine Applications tab in the API section. Do I need to authorize my Regular Web App to us the API? If not then what do I put for the API Audience?
I’m also still a bit confused about when the machine to machine pricing kicks in? What exactly do I have to request/generate in order for it to count towards the limited number of tokens you can generate for Machine to Machine apps?
You will only need to authorize your regular web application in the machine to machine section if you intend for that application to obtain access tokens for the API using a client credentials flow (Client Credentials Flow).
If you check that page you’ll see the flow does NOT involve any user credentials; only client credentials (client id and secret). In this client credentials flow the issued access count will count towards the quota for M2M because it’s an access token issued for the client application credentials.
If your regular web application is authenticating users and as part of that authentication it requests an access token for the custom API then:
you don’t need to authorize the application in that section.
the issued access token is related to an end-user and as such won’t count for M2M quota.