REST API design pattern to register new users without frontend

Question

I am building a REST API with some CRUD resources (in laravel, if that matters). Now I came to the point where I need to add authentication to my application. I personally would like to avoid building a whole user interface (as webpage, etc), but rather stick to a REST API that you can use with curl for example.

But how would you design such a pattern? Should users register through the rest api, should I manually create new users? My system won't have much users, it is just a developer access where I want to give different companies access to the data.

A login/session for REST does not make sense to me, it would also make the API more complicated, especially without frontend. Isn't there a common solution/pattern for that, that people already use?

So questions I am thinking about:

1. Should people use something like /register or should I create users via cmd myself?
2. How do I avoid that strangers could register? Or how would I handle giving out/upgrading permissions for specific users?
3. Should I really create new users or only have a single user (me/admin) that gives out tokens with specific capabilities?
4. How to I manage roles/rights? On a token basis, on a user basis or both?
5. How do I transmit the token safely to the new user? I'd like to avoid having complex email handling as well in my application.

Answer 1

1. Should people use something like /register or should I create users via cmd myself?
2. How do I avoid that strangers could register? Or how would I handle giving out/upgrading permissions for specific users?
5. How do I transmit the token safely to the new user? I'd like to avoid having complex email handling as well in my application.

Given:

My system won't have much users

and your question (2), it should be easy for you to manually manage registration - that is, whoever needs access to the APIs contacts you manually, and you update your user DB manually, and manually send them their access token.

Usually API-based registration requires some access (in case the APIs are not public), and usually some proof that you're a human (eg CAPTCHA). Manual interaction with you provides both.

3. Should I really create new users or only have a single user (me/admin) that gives out tokens with specific capabilities?

It's a really bad practice to have multiple people/agents use the same user. For security, auditability, and possibly some features that you might not be anticipating at the moment, you should allocate a user for each agent/person using your APIs.

4. How to I manage roles/rights? On a token basis, on a user basis or both?

It sounds like your case is simple enough to keep things simple and manage authorization based on users.