2

Lately I have been reading a little bit about HATEOAS implementation in a HTTP JSON REST API(since I making one), and I understand the general concept of links and actions and so on and that there are many some different formats defined such as HAL, JSON API, etc.

What I don't understand yet is what the relationship between HATEOAS/REST and authentication is, or to make it into a more concrete question, what type of authentication should a "proper" HATEOAS/REST API use?

Obviously, it should be stateless, like a JWT token or something like that, but is there any standard and/or rules/guidelines or is authentication totally different subject?

Edit:

To clarify even further, my problem is not that I am having problems picking what authentication to implement, but that I do not know what is required from the API authentication-wise in order to be able to call it a REST/HATEOAS API.

So the (hypothetical) scenario would be: Create an API that can be said to be REST/HATEOAS in every sense of the word and get $1,000,000. Make one minor protocol-violating mistake and get $0. Meaning, the objective is not to do what makes the most sense, is the most efficient or what benefits the developers and/or users, but just to be 100% REST/HATEOAS beyond the shadow of a doubt.

StubbornShowaGuy
  • 249
  • 4
  • 18
  • 1
    REST is an architectural style, not an architecture in and of itself. There are many possible 'correct' authentication systems, even if you narrow yourself down to just REST over HTTP. – Nicholas Shanks Dec 25 '16 at 18:56
  • @NicholasShanks Okay, thanks for clarifying that. So what are some of the possible 'correct' ones, why are they possibly 'correct', and which ones are not 'correct' and why? (I'm not trying to ask for a complete list, just the principle of the thing and an example or two) – StubbornShowaGuy Jan 18 '17 at 14:24
  • REST says "use a uniform interface", which over HTTP essentially means you should use HTTP's authentication system; don't e.g. wrap your authentication parameters somewhere deep in an XML request body (as SOAP does). So anything that uses the (misnamed) Authorization header will work with intermediaries that recognise it. I personally use Bearer (token) authentication a lot: https://tools.ietf.org/html/rfc6750 – Nicholas Shanks Jan 18 '17 at 14:38
  • Other auth systems that work with HTTPs interface are Cookie-based (also often a token system, but without a shared header nomenclature); and putting the username and password in the URL, which you should only consider doing on a private network, and even then you shouldn't do that :-) – Nicholas Shanks Jan 18 '17 at 14:41
  • You need to fullfill all REST constraints https://stackoverflow.com/a/25706876/607033 and all related standards like IRI, HTTP, JSON/XML/RDF, etc. So it is about looking for auth solutions, that meet with these criterias. As of HATEOAS, it is not common to send an auth link, this is usually hardcoded to the REST client. I think it would make sense to have such links only if you want to support multiple auth methods in your REST service and you want to let your REST clients discover which auth method they can support. – inf3rno May 18 '21 at 11:01

1 Answers1

0

Like you said, you should look at authentication in an independent manner.

It's true that token-based authentication systems implemented used by-value tokens do fit well in the stateless world of HTTP based API's so this could possibly be the recommendation to give for most common scenarios. However, you should look into the particular requirements of your scenario to reach a final decision, maybe there's a simpler option available like API keys.

Have in mind that if you choose a token-based approach there's still a lot to consider thereafter. Your API won't be of much use if you don't define a way for applications to obtain access tokens and there are many ways you can go about this, for example:

  • You could roll your own system and define your own processes around how the tokens are obtained and then used by the API in order to perform authentication
       ⤷ (not recommend, time consuming and easy to get something wrong)

  • Implement an identity provider/authorization server system compliant with available authentication standards like OpenID Connect and OAuth 2.0
       ⤷ (time consuming and complex, but by following standards you're less likely to mess up and you'll also gain interoperability)

  • Delegate the authentication to a third-party authentication provider like Auth0
       ⤷ (easy to get started, depending on amount of usage it will cost you money instead of time)

Disclosure: I'm an Auth0 engineer.

Community
  • 1
  • 1
João Angelo
  • 56,552
  • 12
  • 145
  • 147
  • You say I should look at authentication in an independent manner, and I want to know what you base this assumption on? What I am looking for is something like "according to RFC X, Y should be used in a Z kind of way", as opposed to something subjective like "I feel like REST should be used like this" or "My opinion is that HATEOAS should be used like this". Everything after the first line sounds like your (very qualified) opinion on API authentication implementation, which is not what I asked about. I apologize if the question was vague, please let me know if there is something wrong with it. – StubbornShowaGuy Oct 25 '16 at 00:53
  • There's not a RFC for every decision that has to be made in software development. I would like that also, but it ain't so. The RFC and specification to follow if you want to implement authentication and authorization are the ones I linked to originally. They will answer your requirements, but you'll need to put the pieces together according to your specific scenario and requirements. – João Angelo Oct 25 '16 at 07:37
  • I think you are right that there is not an RFC for every decision that has to be made in software development, but I am wondering if there is any form of specification(RFCs or other documentation for that matter) covering REST and/or HATEOAS when it comes to authentication. Are you saying that upon careful examination, you have found that there is none? Are you saying that as far as you know, there is none? Or are you saying there might be, but you think it doesn't matter? (Maybe my question accidentally misled you on what kind of answer I am looking for, so I modified it to clarify that.) – StubbornShowaGuy Oct 25 '16 at 09:56
  • To my knowledge there is no RFC that puts the two together. Depends on your definition of documentation, but it's highly likely there's something around the Internet that puts the two together. I don't think it's worth to spend time to try to find it, if it was any good it would be easy to find. You already know the current standards for authentication/authorization, you already know about REST/HATEOS, now it's putting those two together depending on the requirements. – João Angelo Oct 25 '16 at 10:31
  • I do not want to sound arrogant to someone like you who is kind enough to try to help, but in my humble opinion, with your last comment you moved from not having answered my question to having answered my question in a baseless way(no evidence) in the first half of a comment to your answer, which I hope you will understand is not enough for me to accept it. – StubbornShowaGuy Oct 25 '16 at 10:58