Question

In my “REST API” I would like to use some token based / cookie based authentication. That means, before the API can be used by consumer the consumer needs to obtain this token by calling some Authentication URL with username/password.

Is it OK to just return a Set-Cookie Header?

I think it actually breaks the REST principle but how would you do it (or design the uris and verbs) without HTTP Basic Auth (which means sending username/pwd in every request)?

Maybe like this?

GET api/authentication/signin/?username=abc&pwd=123
GET api/authentication/signout

or?

GET    api/user/authtoken/?username=abc&pwd=123    (signin)
DELETE api/user/authtoken/     (signout)
GET    api/user/               (returning details of the current user)

What about registration then?

POST    api/user/   (which would also return an authtoken)

or?

GET    api/user/abc/authtoken/?pwd=123    (signin of user abc)
DELETE api/user/abc/authtoken/     (signout)
GET    api/user/abc/               (returning details of user abc)

Answer 1

I would treat a session as a resource:

POST /sessions

Creates a session and returns a cookie.

DELETE /sessions/:sessionid

To delete the cookie and log off.

GET /session/:sessionid

To check if the session is valid (e.g. Cookie didn’t expire or otherwise invalidated).

But I think you should also implement Basic Auth or some other scheme that’s standard and require a your custom session stuff to be authenticated via it while the rest of the API could also use the session data via the cookie.