We are constructing an API and plan to make it available to our customers, who will access it using Bearer tokens. Our customers will connect to our API from server-side code (no client-side apps such as SPAs will consume this API). That is to say, 1) their machines will talk to our machines and 2) the client machines are absolutely trusted.
We looked at two options:
- The Client_credentials grant, which is allowable because the customers’ machines can be trusted with the client_secret. However, we need to know which client is calling our API, and a Bearer token obtained via a client_credentials grant cannot convey identity. Therefore this approach would require a separate Auth0 Client for each of our customers. But is seems clunky and difficult to manage one client per customer. What if we have many clients? On option would be to include a custom header in each request that identifies the customer, but again that seems clunky.
- Use the Resource Owner Password Credentials Grant. Create a user account for each customer. When we set up a customer, give them the username and password that we’ve created for them and make the passwords to those accounts never expire. When they need to call the API, their server-side code will use the Resource Owner Password Credentials Grant to obtain a token, which we can parse to know which customer is calling our API. This blurs the line between “user account” and “machine account”, but really is that a bad thing?
I’m leaning towards option 2. Does this approach seem feasible?