2

Guys I need to deploy a very simple authentication API service.

You register with a username (actually an ID with a determined format), a password and uuid. You login with your username and password and if credentials are correct you get back the uuid as a response (JSON or whatever the fuck).

If you forget your password, you can use your uuid (which is confidential, very long string) in some POST request to set a new password. If you forget your username, you use the uuid again in a GET request to get back your username.

I've been looking at a bunch of solutions online and I don't think they suit my purpose exactly and all require emails (Like Firebase, AUth0, etc.) So, let me get this straight: NO FUCKING EMAILS INVOLVED PLEASE.

The above are the EXACT requirements I need for my work (for a good cause too). I fucking hate 0-requirement exploratory research tasks and I'm plagued with those. Those requirements are the only way it should work. So again, NO EMAILS INVOLVED PLEASE.

Also, please note that I have never developed an API in my life. I feel like StackOverflow will be assholes about this so I am asking this here.

I know it is very easy to do and there are probably dozens of ways to do this. I just do not know how, documentations are vague and overwhelming (or I'm just a little stupid lately). Another thing is that I am not sure of how can I do this in the most secure way. Bonus if this can be dockerized.

I know I sound a little rude,so I am sorry. It is just my frustration and depressing times I am going through that's preventing from thinking straight.

Comments
  • 3
  • 2
    OK I see it like that, assuming that the UUID is not a temporary string and will be stored somewhere:

    Ensure that all communication with the API will be encrypted with HTTPS, otherwise this will be not so good for your users.

    Generate and store the UUID in an encrypted environment. When the UUID will be returned to the user only on registration (just my assumption), then use a salt for hashing the UUID in the database, otherwise an attacker might get them and change passwords for all the UUID's he will get and hijack a lot of user accounts.

    And for the registration, just return the UUID to the user as the response. Not the best practice, but would be sufficient.
  • 2
    I totally agree with @jschmold
  • 3
    wut? why not just use a standard Oauth+2fa? maybe link to an otp service.

    That way, you can revoke access in case you need. It will be easy for users to login, and impossible for them to not call It every hour.
  • 4
    Sounds not bad
  • 1
    Thank you all for your suggestions. I am mostly aware of the recommendations you gave. It's just the requirements of the business. Kind of a portal of patients who are probably not good with tech. I found what I am going to work with and I believe you guys could take a look at it too. I will use it and keep in mind the recommendations you provided.

    fusionauth.io
Add Comment