Hi,
is there a possibility to communicate with openboxes backend api via api-access-key or api-secret-key and not with cookie?
Great question.
At the moment, no. But it’s on our roadmap. We would like to add a more suitable authentication mechanism for the API in addition to providing more fine-grained role-based access control (RBAC) for features across the system.
We’ve built a proof of concept re: Basic authentication
and an OpenID Connect flow
I decided to hold off on merging these (as well as an OAuth 2.0 flow) until we had a chance to do this properly using a library like Spring Security (or Shiro). This will be possible once we finally get the official 0.9.x release published in the next few weeks.
Can you elaborate on your use case and reasons why you want API keys? Are you just annoyed that it’s tedious to deal with cookie-based authentication? Or is it more about the fact that you’d like a more secure mechanism that lets you generate API keys that can be granted and revoked?
If there’s a compelling case, I can at least work on getting the Basic auth mechanism merged into the codebase for one of the next releases. The security refactoring is probably not going to happen until later this year at the earliest.
Justin
Hi, thank you for your answer 
It is this one “Are you just annoyed that it’s tedious to deal with cookie-based authentication?”. Would be way easier to communicate with api via api-key
But no worries. We will be fine with cookies. Just wanted to know, maybe there is a better way 
Cheers!
P.S. But if you are finished with the basic auth. Maybe your are planning to merge it sometime soon?
I was finished with the basic auth code years ago, but didn’t merge it and can’t remember why. I’ll investigate whether there was a reason for that, figure out the level of effort to port that PR and add some tests.
I can see that basic auth “/login” endpoint exists now and I can login with it. But when I try other request after basic auth - it returns login screen. Like I’m not authenticated. So I guess it is not implemented fully . Maybe it is easy fix and I could implement it in my forked version?
Basic authentication would be an auth mechanism that allowed you to send a base64-encoded authorization string (username:password) for every request via the Authorization header.
That’s what we don’t currently support right now but would be available if/when I merge that branch I mentioned in the earlier message.
That login endpoint you mentioned is just an endpoint that allows a user to authenticate to create a session on the server. Once you log in you need to keep track of the cookie on the client and pass it back on every request. You’ll also likely need to provide a location, either during the login attempt or using the chooseLocation endpoint.
What are you using to test the API? Postman? cURL? Something else?