20
linuxxx
24d

Currently working on my first real REST api and I've arrived at the authentication part.

I'm not sure how to do this one, the client will have to login using username/password but then, what's the most conventional way of authentication logged in users through a REST api? (no oauth (yet))

This should be usable for anything like ajax requests to calls from the backend to curl requests.

Looking forward to ideas!

Comments
  • 11
    How about JWT bearer tokens?
  • 2
    https://en.m.wikipedia.org/wiki/...
    The easy way instead of OAuth.
    TLDR:
    Send as header in request:
    "Authorization: Basic " + base64(username+":"+password)
    and somehow check that serverside.
  • 14
    @Forside unencrypted credentials / cookies over http seems like a terrible idea.
  • 1
    I would go for something simple JWT or alternatively go with basic/digest depending on what is the nature of the clients (is it safe to have the secret client side or not)
  • 0
    @olback pretty sure you can't revoke the tokens if they get compromised... Also seems unsafe in case of account compromise.
  • 3
    I'm usually doing this with a classic post request containing the credentials in JSON which then returns a jwt token which can then be used to authenticate future requests. Take a look at https://try.vikunja.io/api/v1/... under the user/login section.
  • 2
    Imo either have the users request have an api token or use a session cookie.
  • 0
    @Forside the problem with basic auth is you need to verify the credentials at each request, which can result in higher database loads.
  • 1
    @FMashiro You can still hash the password beforehand.
  • 2
    @kolaente I'll use redis a lot for performance reasons.

    Thanks people! Didn't expect this much response 😁
  • 2
    @Forside true, but client side hashing is meh at best, also, how will you get the salt there in the first place? Or don't you use a salt?

    The client side hashing is meh because of the limited availability of hashing algorithms by the way
  • 2
    @dev-nope I'm solely the api builder/hoster, people can develop stuff around it themselves so I don't think so :)
  • 0
    @linuxxx but you still need to verify the users password, which can create load on you server (and, more importantly, waiting time for the user) for each request.

    (I'm assuming you're using some good hash algorithm like bcrypt here)
  • 1
    When user registers store sha2048 hash of his passwd and assign usename to that. Once he wants to login just hash what he writes and compare.
  • 3
    @kolaente True and yes of course, nothing less than bcrypt!
  • 4
    @Haxk20 This isn't about password auth ;)

    It's about REST api authentication *after* login!
  • 5
    @FMashiro I like salt on my cucumbers 🥒🧂
  • 3
  • 0
    Have a look at auth0 services. It does this for you. Or cognito on AWS. Depending on what your API is implemented in there is also Django authentication.
  • 3
    JWT Token. I'd go with that. Auth user first time with form. Return token on success. Send token on authentication header for subsequent requests.

    https://jwt.io/introduction/
  • 1
    @linuxxx ah i see. Well idk about that then since i never worked with it.
  • 0
    JWT works great. I'm using it with Strapi and Angular.
  • 1
    Jwt tokens are the way to go if you don't want to store every token. Only thing is you would need a endpoint to invaildate tokens that are still valid(jwt has an expiry builtin). Since you use redis you're already halfway there since most people store invalidated jwt tokens in redis until they expire anyway
  • 0
    I'd go for session IDS (meaning it bring treated like a JWT on client-side but not Holding any data. Association, etc is stored server side
  • 0
    A token is probably the way to go, that is linked to a user, though.. that's what I see everywhere.

    PostNL user:token (was user:sha1(pw))
    BigCommerce user:token / oauth
    ...
  • 0
    I always go for JWT tokens, I have a table for them in my database so that if a user revoke access for that token it just stops being accepted.

    I just do that cuz I set it to be valid for a year
  • 1
    @gitpush Doesn't that sort of defeat the purpose of using JWTs?
  • 0
    @Paralax which part exactly?
  • 1
    @gitpush Shouldn't JWTs allow you to reduce the amount of db queries? If you store them, couldn't you just use sessions?
  • 0
    @Paralax I store revoked ones only and yes it does require db access I know my method is wrong but i need to implement oAuth later on just have no time for it. Or I'll be reducing it's validation time
  • 0
    You can use azure active directory to authenticate users for free, wrote an article on codeproject about it years ago on how to implement role based access control
  • 3
    @gruff Thanks for the suggestion but I refuse to use anything related to the big (in this case I mean Microsoft/google/facebook at least) :)

    I'm going with the JWT approach.
Your Job Suck?
Get a Better Job
Add Comment