I am about to develop a REST API that will only have one "user" and I am curious about how I should implement security to make it as secure as possible(hopefully implementing some protocol that I am currently unaware of).

So initially I thought about implementing openID connect, however I believe that this won't be possible as the one user is an API that should be able to access my protected resources without user intervention.

I guess the question is: is there a standardized security protocol for these sort of cases, or does everyone just "go with the flow" and implement whatever works?

3 Answers 3


From personal experience it might be simpler to implement a keystone with a key that you only issue to the one user, vs. using the username/password authentication method, other than that I'm not sure what else you'd have to worry about. Maybe there is a way to combine both ways, but API's are usually set up so multiple clients can take advantage of the functionality, so a key might be the simplest way to restrict it to one single user.


You can use X.509 authentication and rely on mutual authentication (server authenticates you and you authenticate the server).


Even though this question has been answered, the OpenID Connect Client Credentials flow is a perfect way to secure your API with a key. This flow is specifically meant for clients that are not actually users, such as APIs and other system processes, and requires no user intervention. This allows you to easily expand to more clients, each with their own unique keys and access permissions, as well as enabling you to mix in regular human users if and when that ever becomes necessary.

  • I did not know about this flow, but as you describe it, it is probably the best choice to implement. Although I am going to keep the accepted answer because of the simplicity of the suggested flow.
    – munHunger
    Jul 6, 2017 at 12:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .