-2

Here is description of my app I'm working on. On the client-side (index.html) a user can interact with a data. When he needs to call a server operation for example reading or writing a file on the server, he must authenticate himself and send JS async request. The index.html and API are hosted on the same domain.

The first way I see is to pass at every request an identifier (it may be username, email or phone number), authenticator i.e. password, operation name e.g. read or write and argument i.e. file path (and file content if writing). Since we talk about async requests without reloading the page in the browser, user can type credentials only once and JS will store them in its memory until the user reloads the page (it will mean signing out). I think to store user data in JSON files above the public directory.

When a user sends an async call with the credentials, with the server operation name and the argument(s), the server verifies the user credentials, retrieves his role, sees whether the role has permission to run the passed server operation with the passed argument and if so, performs the operation. I mean one role can not run writing operation at all and can only read files, another role can write files, but only in a specific directory (i.e. specific argument) and so on. That is how I see the scenario.

I don't know authentication solutions and issues very well, so I need your useful advices. Maybe it would be better to use modern OAuth-based scheme in my case with redirect to authentication service and JWT? If so, is there a custom and fully self-hosted solution which is made like the scheme (i.e. instantiating authentication client signIn() object in JS, then using its status and tokens etc.) so that I can use it on my server without additional third-party server, but can switch to another the same solution with authentication service at anytime? Or maybe you see another better scenario for my case?

Would be thankful for any ideas, advices and information

1 Answer 1

2

The first way I see is to pass at every request an identifier (it may be username, email or phone number), authenticator i.e. password, operation name

Please don't do that. Instead use one of the common authentication flows to create a token you can send along your request.

user can type credentials only once and JS will store them in its memory

Applies also to that, never save the credentials (username/password) anywhere else than encrypted in db.

Normally you would separate authentication from your application if you have more than one app the credentials of the user should be valid for.

With this you would have a auth server were you login. This server appears a token after successful login which is sent along with the request to your web application. Your web application takes this token and checks against the auth server if your token is valid. If yes, you could perform further actions.

However, this is just the login part. No authorisation til now. Thats something you can have by roles/groups in your app as you already mentioned or also external depending of the requirement of you application.

If so, is there a custom and fully self-hosted solution which is made like the scheme

Have a look at Keycloak if you search for open source software

2
  • Thanks! Agreed that a token is better than initial credentials at every request to the server. However, what about services using API key for access to them from the first request, so that such key is like initial credentials? Is the point that's a long and random string?
    – stckvrw
    Jan 10, 2021 at 11:52
  • The point with all of them is to minimize the usage of the "real" credentials (only on first request). With this you have less risk for abuse and more control about validity, permissions etc. ... both API keys and tokens have their pros and cons ... API Keys are often used when developers only are accessing the resource while tokens are useful accessing data without having contact to tokens, keys or other secret etc. (think of the typical "servicexyz wants to: -access user data, -share posts in your name ... " etc.) usually you don't notice any technical things which happen in background ...
    – Jim Panse
    Jan 11, 2021 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.