Hello there, I’m new to Auth0 but I’ve read a lot of documentation in the last few days. Still, I can’t find a clear way to do what I’m looking for, which looks very simple to me, but I must be missing the point.
As the title implies, I have a username and password in configuration (server-side only) and would like to connect the user behind these credentials to Auth0. The main point is to be able to read and update the user-metadata.
For now, I assume that using a username-password pair would be the best way to do it, but maybe I’m wrong and there a better way to create an account for a server?
If you wonder why I need an account for my server, it’s simply that this server will be installed in our customer places. Each of our customers will be a different person/entreprise and need a proper account to be able to exchange with others.
To be absolutely clear, this is a machine-to-machine scenario, I cannot have a login screen or callback uri. I just mean to call one or more endpoints and receive the information I need.
Is this possible? Maybe I should use another approach?
Thx in advance to the community
Welcome to the Community! It sounds like you want the Client Credentials flow. You create M2M client in Auth0. authorize that client to access the associated API (management API with read:users scope in this case), and use the client ID and client secret in your app to talk to Auth0.
This could get complicated if you are deploying the software to many locations.
Pretty much … you need some sort of authentication. Of the available flows, client creds is the one that fits your model. Client creds is used whenever a server / service needs to talk directly to an authorization server without a user involved.
I might be misunderstanding exactly what you are trying to do (correct me if I am wrong!) but it sounds like you are trying to basically “fake” the client credentials flow with an actual user account. You could use a username + password instead but that is complicating the scenario… you’re doing a full OIDC login where you only need to pass a client secret.
In either case you need to store and provide a secret (client secret or user password) so I’m not sure what using a user account buys you in this scenario.
I may be misunderstanding the usage of this secret, but it seams to me that it allows to modify quiet a lot of thing, while a password would have a closer range. The point would be to avoid each server being able to change everything for the others.
The secret just a password. The actual “client credentials” (client ID + secret) are a “username and password”, but for machine-to-machine scenarios where a person is not at the keyboard.
What the server is authorized to do after it authenticates is controlled by what scopes your assign in the management API. If you want your app to be able to read user data, you need to assign the read:users scope. E.g.,
Thank’s for you quick and very well explain answers. I think I’ll go that way for now, but I still feel a little ominous: If all my servers do share the same account, they will all have the same rights. Which is of no importance in case of read access, but is problematic, kind of, in case of write access. Just to be sure, do having one account by server, and therefore each server only be able to modifie it’s own data be possible ? Would you happen to have a tutorial as clear as the previous one you point me at ?
In any way, thank you again.
One Auth0 Tenant per Customer: Each customer gets their own tenant, completely separating all data and code. Advantages: clear separation between customers, customized tenant configuration per customer. Disadvantages: Maintaining multiple tenants!
Single Tenant, with One User Database per Customer: Each customer gets their own user database, but in a single shared tenant. Advantages: probably easier for you to maintain, possibly opportunity to share code between customers, user data still separated. Disadvantages: less flexibility at the tenant configuration level.
Single tenant, single database: This is probably not a good solution, unless the customer data should be shared between customers. You could use a single database but including data in the user profiles that allows you to differentiate users by customer. Then your app could handle what data each customer can see. This model has the greatest risk of a data exposure.
In either case above, each deployment of your software would have its own Application (Client) in the Auth0 dashboard, and therefore its own unique set of client credentials. Authorized scopes can be adjusted for each deployment of your application as appropriate for that deployment.
