Login/Logout Links in HAL

30 views
Skip to first unread message

Icke Bins

unread,
Oct 29, 2021, 7:25:07 AM10/29/21
to HAL Discuss
Hi,

Would you list a logout link for unauthenticated users?
Would you list a login link for authenticated users?

My question goes about api-documentation vs. list links for possible actions/state transitions only.

Thx


Joost Cassee

unread,
Oct 29, 2021, 7:41:56 AM10/29/21
to hal-d...@googlegroups.com
Hi,

As I create APIs using OAuth, I often include a link to the authentication info but no "logout" links. I have appropriated "http://openid.net/specs/connect/1.0/issuer" as a link relation, although it's not official.

Best,
Joost

Op vr 29 okt. 2021 om 13:25 schreef Icke Bins <ick.bi...@gmail.com>:
--
You received this message because you are subscribed to the Google Groups "HAL Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hal-discuss...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hal-discuss/362072d8-e81c-49f4-91d6-c9c06a0a2b5cn%40googlegroups.com.


--

Evert Pot

unread,
Oct 29, 2021, 11:29:31 AM10/29/21
to hal-d...@googlegroups.com
Hi Icke,
We do. I've written this draft to standardize them:

https://datatracker.ietf.org/doc/html/draft-pot-authentication-link-01

So far reception has been pretty positive, and there is some adoption.

Evert

Icke Bins

unread,
Oct 29, 2021, 3:47:13 PM10/29/21
to HAL Discuss
My question was not if these rel's should used but if they should always included in responses.

When the user is already authenticated - why should I provide him an authenticate-rel? He is already authenticated.
And vise versa: When the user is NOT authenticated why should I provide him a logout rel? He cannot logout because he is not authenticated.

mca

unread,
Oct 29, 2021, 3:52:57 PM10/29/21
to hal-discuss@googlegroups com
In my opinion, it is better to only include links/forms when they are relevant to the current context/user.



--
You received this message because you are subscribed to the Google Groups "HAL Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hal-discuss...@googlegroups.com.

Evert Pot

unread,
Oct 29, 2021, 4:02:36 PM10/29/21
to hal-d...@googlegroups.com
On 2021-10-29 15:47, Icke Bins wrote:

> My question was not if these rel's should used but if they should
> always included in responses.
>
> When the user is already authenticated - why should I provide him an
> authenticate-rel? He is already authenticated.
> And vise versa: When the user is NOT authenticated why should I
> provide him a logout rel? He cannot logout because he is not
> authenticated.

Personally I find this difficult to answer. I think there's a lot of
different degrees and ways people adopt HAL/HATEOAS. There's a large
number of people that keep most their logic client-side, and just use
links for relationships between data and discovering endpoints, and I've
seen *some* that are on the other end of this, and they try to
comprehensively describe the full application state in each response.

I find that people who are in the latter category tend to use HATEOAS
for simpler/constraint user experiences. For example, this could be a
great fit if you are building a survey system. I also feel that for
these cases, you probably want to follow what is sometimes called a
"Backend for frontend" pattern.

Anyway, all of this cruft is just to sum up... I don't think there's a
great universal recommendation for this, because it depends on what your
goals are and the type of clients you want to serve.

Evert


futy...@gmail.com

unread,
Nov 12, 2021, 9:47:20 PM11/12/21
to HAL Discuss
I absolutely agree that there is no reason to return links, which are not useful in the current state.
Personally I found the only place for login link in the response with status code 401 (UnAuthorized). In this case the Client won’t need a separate process for authentication, just request the entry point (root) resource and if needed handle 401 status. This will be just like handling any other request (any request may return 401 if session expired or killed by admin).
As for logout link, I would put it in the root resource only, so do not replicate it everywhere. The entry point URL is directly accessible for the Client, so for logout from anywhere it can request root resource to find logout link.

Reply all
Reply to author
Forward
0 new messages