Test other authentication mechanism

[djschilling]

Currently basic authentication is used to authenticate in the api.

I'm not sure if that's the best way in a server-client application.

Other authentication mechanisms like oauth should be tested.

[flash1293]

What about HTTPS and a GET-Endpoint which delivers an API-token that has to be send in every request as a custom header (rmt-auth: 123ab23d312c231af131)? With this method cookies are not required for the client and it is easier to write applications that will not run in a browser.

I don't like O-Auth from the usability-perspective.

[djschilling]

I think HTTPS is a different aspect of security which is also important but not related to authentication.

Why dont't you like O-Auth from the usability-perspective? It would be a token based authentication mechanism and it seems to be the easiest entrypoint for users?

[flash1293]

In O-Auth, the users wants to log in on one page (frontend) and is redirected to another page (backend), which I think is confusing. Wait, do you mean O-Auth in combination with a Facbook/Google-account? In this case I think it would be pretty nice. Also what about non-human users? Do they need a separate auth-mechanism?

[djschilling]

I think this "confusion" could be hidden from the user if i understand O-Auth correct, but i thought about the combination with a Google/Facebook/Github-Account. So no one have to create a useraccount and we have only valid users.

Why do we need non-human accounts?

[flash1293]

Login with Google/Facebook/Github-Account: +1
We don't need non-human accounts, but it is a nice feature which may be handy later.