Timeline for Which authentication method to use?
Current License: CC BY-SA 4.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21 at 4:54 | review | Close votes | |||
| Oct 26 at 3:01 | |||||
| Jan 20 at 13:48 | comment | added | Joao | @Caleth You're right man. So, what you suggest in my case? | |
| Jan 20 at 13:27 | comment | added | Caleth | @Joao so, not private? If it has a public IP address anyone can send requests | |
| Jan 20 at 13:25 | comment | added | Joao | @Caleth I mean it is not in LAN. It's private because it only works between my website and my REST API, but it uses the internet, not a LAN. | |
| Jan 20 at 11:32 | comment | added | Caleth | What do you mean that it is "private, but not internal"? | |
| Jan 17 at 13:37 | answer | added | D4LI3N | timeline score: -1 | |
| Jan 13 at 18:07 | comment | added | Joao | @BenCottrell The API is private, but not internal... Only the website will consume these endpoints. | |
| Jan 13 at 17:53 | comment | added | Ben Cottrell | @Joao Is there any specific, measurable objective here? Based on the comment thread so far it sounds you have an private, internal API which isn't even accessible over the internet, and is therefore already secure from all the usual threats - and perhaps the API simply doesn't even need its own authentication, as it doesn't sound like it would actually give you anything that you don't already have. | |
| Jan 12 at 19:00 | comment | added | Joao | @freakish Besides an apiKey... What else can I use in this scenario? | |
| Jan 12 at 18:59 | comment | added | Joao | @freakish Yeah man, that's it. I just have a service with a singler user, the website. I just wanted to confirm how it is usually done in these cases, as I didn't see any text or tutorial on the internet explaining it. And when I referred to "all", it's all the videos talking about authentication, in its entirety it's all about authentication of multiple users on the same REST API with login/password and token | |
| Jan 12 at 8:36 | comment | added | freakish | I don't know who those "everyone" is, but for example every database is a service which you access from a webserver. And none uses just apiKey. And in fact, I don't think any production ready service uses just apiKeys. | |
| Jan 12 at 8:35 | comment | added | freakish | @Joao apiKey is nothing else than password without login. Or in other words you have a service with a single user. That's obviously less secure than login+password. And also less flexible, since different services can access your service with different users, with different privileges. | |
| Jan 12 at 1:04 | comment | added | Joao | I'm choosing to use apiKey... Both my website and my REST API use https and it seems much simpler for both to communicate using an apiKey that will never be available on the client side as the calls will be made in Server Actions in NextJS. Everyone talks about logins and passwords for people to access normal apps, where it is important to upload their data, but what is used in these cases? | |
| Jan 11 at 21:45 | comment | added | Joao | I know about that... The question is: use the traditional login and password or apiKey or other? | |
| Jan 11 at 21:01 | comment | added | freakish | @Joao client makes request to your server, which then makes request to the administrative API on his behalf. Client is not even aware of the other server, and doesn't care about its domain or cookies. | |
| Jan 11 at 18:21 | comment | added | Joao | @freakish That's right, but you don't forget about the cookies. How can I, on the server side (server actions), record cookies in the client's browser since the REST API is in another domain? Don't forget that it uses cookies to transmit tokens. Therefore, this tactic would not work for the scenario of these administrative endpoints. | |
| Jan 11 at 17:34 | comment | added | freakish | @Joao it is not the user that is supposed to sign in twice. But the website, as in: the webserver behind it should sign in to the other webserver. Machine to machine, behind the scenes. | |
| Jan 11 at 17:05 | comment | added | Greg Burghardt | This sound like something JSON Web Tokens would be a suitable solution for. | |
| Jan 11 at 14:44 | history | edited | Philip Kendall | CC BY-SA 4.0 |
Remove unnecessary bold text.
|
| Jan 11 at 14:39 | history | edited | Joao | CC BY-SA 4.0 |
deleted 4 characters in body
|
| Jan 11 at 14:39 | history | edited | Joao | CC BY-SA 4.0 |
added 778 characters in body
|
| Jan 11 at 14:33 | comment | added | Joao | @freakish Please check the previous comments... What do you think now? | |
| Jan 11 at 14:31 | comment | added | Joao | @esqew Because my site has your own authentication system, different from REST API authentication. These are administrative endpoints that will be used by this website. It would be redundant for the website user who has already logged in and has administrative privileges to have to log in on another screen providing the REST API credentials just so that these pages have access to these endpoints. Did you understand? | |
| Jan 11 at 14:23 | comment | added | Joao | @GregBurghardt... In fact, only users who have access to these pages, through the site's own authentication system, will access them and therefore they will consume the REST API that uses another authentication source. I discovered something called API KEY, which seems to fit very well with what I want. In this REST API, these endpoints will only be accessed by my website and through these pages. I am calling these endpoints through an Action Server (NextJS) sending an API KEY and there in the REST API I check on these endpoints whether the API KEY checks, and if so, access is granted. | |
| Jan 11 at 6:57 | comment | added | freakish | "In this case, it would be strange for me to create a login/password for the website." On the contrary: that's exactly what you should do. | |
| Jan 11 at 5:35 | review | Close votes | |||
| Jan 20 at 3:01 | |||||
| Jan 11 at 1:15 | comment | added | Greg Burghardt | And who are the users of your NextJS app? Are they people or other programs? | |
| Jan 11 at 1:03 | comment | added | esqew | “… it would be strange for me to create a login/password for the website” Why…? How much different is this than issuing a client ID and client secret? | |
| S Jan 11 at 0:20 | review | First questions | |||
| Jan 13 at 7:51 | |||||
| S Jan 11 at 0:20 | history | asked | Joao | CC BY-SA 4.0 |