Why would one use iron-session instead of next-auth? Doesn't next-auth do normal username/password log-in in addition to Social (while iron-session only does the former)?
next-auth does a lot of things like you said but it also makes you do things their way. So you have to model your database a certain way to make next-auth work but it does come with a lot of helper functions and makes you write a lot less code.
iron-session only does session management. You have to write all the auth logic with iron-session which next-auth handles for you automatically.
As far as which one is better: if you'd like complete control over your database then use iron-session because sometimes next-auth might not work and it's annoying. I faced an issue with it so ditched it but it just might work for you. iron-session gives full control but you have to write the correct code. Personally, I'm facing issues with iron-session as well with useUser hook because I have to use react-query and not swr but it's probably my issue.
iron-session is lightweight library. It is simply used for session management. session is not related only to authentication. For example, maybe you want to sign some data on one API endpoint, attached the signed data to the req.session and you still need to reach this data on a different API endpoint iron-session store data on the encrypted cookie and save it to the browser. From here:
Node.js stateless session utility using signed and encrypted cookies
to store data. Works with Next.js, Express, and Node.js HTTP servers.
The session data is stored in encrypted cookies ("seals"). And only
your server can decode the session data. There are no session ids,
making iron sessions "stateless" from the server point of view.
On the other hand, next-auth is a more robust authentication package. as the name says next-auth, it is dedicated to authentication. It has too many authentication methods. It creates a session specifically for the user's login
Related
I've a situation where I'm creating a Blazor Server front end for an API, and that API may also be used directly by some other systems. Essentially some smaller customers might use the UI, others (perhaps larger with their own dev team) build their own UI and use the API. We control both sets of code (for the Blazor and the API).
Auth in the api is done (at the moment) by sending a userid and a password and getting a JWT Bearer token that is added to all subsequent requests.
Auth on the BS app is (at the moment) done using Azure AD B2C; the templating in VS makes it an easy setup and then no really specialist knowledge is needed to maintain and add new users
There isn't any special link between the two for now; both are in dev and the BS app just has a hard coded u/p for a single dev user inthe API side. At some point that needs to change so the API serves more than one customer via the UI
It seems I have a couple of routes I could go down:
Make the BS app use the API for auth; in my mind this looks like setting up something similar to what you get when you make a new BS app with "Individual Accounts" auth, except it doesn't use EF on a database with tables for tracking identity - it would probably use a custom store and usermanager that asks the API for auth instead of some DB, and then some (hopefully simple) mechanism of getting the returned token from the API into every httpclient that ends up being used to poke the API (they're abstracted away into proxies built by NSwag but it's easy enough to address because NSwag code calls a particular overridable method to setup the headers.. finding a way to have the httpclientfactory do it might be even easier)
Make the BS app and the API use AD B2C for auth. As a workflow I genuinely have no idea how that's done or what it looks like.
Of the two I'd prefer the latter because it hands off some additional responsibility to AD, such as maybe in future we want to have UI customers also do 2FA but I'm not really sure how to go about researching it. How do we go about sharing auth between the two systems?
I'm not looking for code; some rudimentary instructions on how to share the authenticated identity between the BS app and the API is really what I need. If it's not an achievable goal, what alternative mechanism for Blazor Server do I have that would allow easy sharing of a retrieved bearer across a everything the user might do in a "session" (I don't mind if they lose SignalR connection and have to log in again)?
If either of the approaches above look like I'm just making life hard work, and it should be done another way, an outline of the steps required to make it go would be ideal
I am a newbie in Javascript and Vue.js. Try to learn more about it. Now I will be facing a problem when calling an API login that will display a password in the request payload.
I was wondering it does not secure, right? And if it was correct. How to hide it from the browser?
Anyone please help or suggest to me.
This is a pretty heavy topic and the question is not very specific, so I'll make some assumptions along the way.
calling an API login that will display a password in the request payload
I suspect you mean that if you're looking into the requests in the browser dev toolbar, the password is seen.
If this is the case, this is expected and can't be 100% mitigated. I've known people to assume that this means that this means that the data is not encrypted and develop custom solutions to obscure the sensitive data. The thing to keep in mind though is that the browser already does the encryption for you as long as you use https. The encryption happens after the request leaves your browser, so you're not seeing it as encrypted, but it travels to the designated server in a way that hides the content for anyone in the middle. If you add some additional encryption system, you're adding complexity and as long as you're passing the key as-well, the "man in the middle" has access to that too. The endpoints within the target server are also encrypted, so you could even use GET to pass sensitive information without anyone between your browser and server knowing what it is, but don't use GET, since POST has additional benefits like not storing the values in your url cache and the server is less likely to be storing the data in the logs.
When using https properly, your data will be encrypted between browser and server.
You should be using POST requests for sending sensitive data
Avoid adding custom encryption on top of https. It will add more complexity than security.
There's also some considerations around storing the token in LocalStorage vs cookies. The final decision on which is better is inconclusive, but as long as proper precautions are taken, they can both be secure (though I think cookies can be more secure, but only if you make them inaccessible by js, so it makes working with them in context of an SPA harder)
I am building app using SailsJS as backend and angular as frontend. On many websites I have found that auth is done by setting req.session.userID to som value but then in policy it only performs basic check like if(req.session.userID) but I am not sure that this is secure. What if I put some random string to my cookie named userID will system consider this as valid login?
For example my correct userID is ABCDEF but what if some attacker come by and he sets his cookie userID to DEFGH. Will system consider this as valid login? I don't think that there is some background validation against database going on. Wouldn't it be better to create model called Sessions which will store randomly generated session ID and associated userID? Then the system at user login would generate random sessionID which will be stored in DB and in policy system will check if currently set req.session.sessionID is valid.
I am asking this because I don't have very deep understanding of sails but from my point of view solution proposed in documentation doesn't seem secure.
I recommend that you take a look at JWT and how it solves some problems. Then another problem will be "how to store this token". And that you can solve with cookies, local storage, etc. all depending on your needs and possibilities. Usually a local storage + middleware in the client side with reddis on the server side (advanced session behavior) is enough.
I am using play framework to develop a web app. Now I need to implement authentication/authorisation without database (really strange requirement). There will only be log in and log out function, no registration. The username/password pair will be authenticated using external service.
Due to limited experience, my current idea is to use token to authenticate and a local file to store username/password.
Is my idea feasible? Is there any recommended libs? If I use token, do I need to pass that token in Http request/response every time and authenticate the token in every controller?
Thanks!
Why store user name and passwords in a local file? I don't see the point and this constitutes a database, which you want to avoid it seems... Deciding to work with local files will be an important limitation if you ever want to deploy more than one server and have some load-balancing done.
Playframework is stateless, meaning that the server doesn't keep session state. To work around that play uses signed session cookies (the browser is storing the session data, and cannot modify it as the session data is signed).
Here's what you can do:
on login: set some data in the session
on each subsequent request, determine the state (logged-in or not) based on the session cookie, see https://www.playframework.com/documentation/2.6.x/ScalaActionsComposition#Authentication
on logout: reset the session cookie
Now this approach has a serious downside, it allows people to replay (reuse) old session cookies to pretend being logged. Another (could be less serious depending on your requirements) is that it is not straightforward to implement session expiration after a certain inactivity.
This is probably enough to answer your question and give you a starting point.
I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.