I am building an nodejs server and i decided to perform authentication via active directory.
So my first question: is it possible with nodejs? If so, could someone please direct me towards a relevant article/documentation/plugin?
My second question is about the authentication itself.
My server is restful so i basically have to give some form of identification every time i request something from the server.
I though about the next flow:
At the login page in the client, i send username and password to the server.
At the server i authenticate with active directory using the credentials that the client have sent.
Once i receive a response from active directory, i check if it is a valid response and if the login was successful, i also check if the user have proper permissions in active directory to use my services.
Once all that is validated, i create a token for the user.
Every request from the client would have to contain a valid token.
This seems like the most standard way to approach this problem, it is much more simple and secure than sending the username/password with each request and authenticate with active direction every time.
However some thing bother me.
For example: What if the system administrator decides to remove a user from active directory or remove his permissions to use my services? That user still have a token that allows him to access my services.
I could set an expiry to the token, but unless that expiry is one second, the server won't be really at sync with the active directories.
Do you think that tokens is the way to go with this problem? Or should i just do it by sending username and password each request?
Another way is to give a token to the client but on the server, associate that token with active directories username and password. Every request, the server would authenticate with active directory? Is this a good way to go?
Thanks,
Arik
I'm writing this a little bit too late but: I'm creating also a node.js ember app which uses the node-activedirectory. Ofcourse it's possible with node.js: node-activedirectory or ldapjs. I don't know nothing about the second question unfortunately. Yes it's possible to check. You can use authenticate function from node-activedirectory, and then a isMemberOf function. node-activedirectory is working well, so You can authenticate every time, it's note a problem. Yes, if the user is logged, He will be logged until the session or cookie expires(whatever You want to choose), or You can create something like: every time after refreshing page node-activedirectory checks only if user exists. userExists
I hope I've cleared out some of your thoughts.
Greetings, Rafał
Related
I'm working on a react app where the pages can be used both by authenticated and anonymous users. The pages show more features for the authenticated users.
If a user previously has signed in and revists the website, I want the user to be automatically authenticated, and am struggling to achieve this.
I'm using redirect methods because I don't believe popup is working well on phones (is that assumption correct?).
I have tried storing the homeAccountId in local storage and use that to get the account used and then calling login in the msal instance. I also set up a addEventCallback and listen for EventType.LOGIN_SUCCESS which I use to set some internal state about the logged in user.
I have tried using MsalAuthenticationTemplate but strangely this doesn't invoke a login. I have also tried to detect if this is a "first run" and then invoking the login, but that doesn't work all the time. Sometime I get a SSO error indicating I should provide a login_hint or sid which is not possible because I use B2C.
If I don't do anything the user can click the login button and if the user has a valid cookie with B2C the user is logged in without providing credentials which is a strange behavior for the user because my website indicate the user is not authenticated (and show no logout button).
So I can't really get this to work and are wondering if somebody has a concept for achieving this?
Please checkout the msal-react samples which all demonstrate the behavior you're looking for. The MsalAuthenticationTemplate would be the recommended way to do this and if you're still having issues getting this to work after reviewing the samples I would recommend opening an issue on our repo with code snippets so we can take a closer look at what's going on.
Also using localStorage, if you're not already, would help to maintain application state between browser sessions. sessionStorage is the default.
As for B2C not asking for credentials; server state is separate from client state. You can be signed in on the server without the application knowing about it. Until your application makes a request to the B2C server your application will show that a user is not signed in. If a session already exists on the server when you make a login request, the server may redirect you back to your application without asking for credentials again.
I want to use google oauth api to log in to the site which I create.
I use react and node and I'm done with getting current access_token issued but I'm not sure how to know if the user is logged in.
Should I check the user's access_token every time the user calls the api of my site?
If that's correct, should the access_token be held by the client?
Isn't that a security issue?
I did a lot of searching but I don't know how to manage access_token and how to check if user is logged in.
This is the article I referenced
Should I check the user's access_token every time the user calls the
api of my site?
Yes. The only ones you will not check will the public ones.
If that's correct, should the access_token be held by the client?
Yes, it can be stored in cookies, local storage... Is is debatable which is the best solutions, you can articles such as this one
Isn't that a security issue?
No. Anybody can check the content of a JWT token (just paste the content here). But the neat thing is that it can't be modified or manipulated. Of course, it is advisable to keep it as safe as a password, so don't share it around :)
I would like to use Active Directory with a REST API Express backend: users would fill out a username and login form on the client side, and get authenticated with their Active Directory credentials, through the backend. Then, based on their user groups, they would see certain information. I have tried the node package passport-windowsauth, but I am not able to authenticate, possibly because I don't know what the bindDN or bindCredentials are. I have also tried node-sspi, and had better luck with this, but the issue with this is that it's only server-side, and as far as I can tell, I can't create a form that would then allow the user to authenticate from the client side. I am hosting this site on IIS, and using iisnode for the backend. How can I can achieve this Active Directory authentication with Node/Express server-side and a client-side login form, or in other words, not a .NET application?
Active Directory (AD) authentication is accomplished by binding to the Active Directory with credentials (not the credentials from the User form) supplied by your AD engineers. After binding, AD is searched for matching credentials (from the User form).
Basically you need to talk to your AD engineers about what you should use.
Then you need a /login/ route the user form sends to, the route accomplishes the login (AD bind, authentication) and returns to the client.
A simpler workaround can be to bind to AD with the credentials entered into the login form - a successful bind means the user is logged in. I would, again, talk to your AD engineers about how they prefer this to be done. I've run into problems in the past where it's taken a long time to authenticate users after binding so we used this as a workaround.
You might ask if your AD already has single-sign-on options - maybe they use Shiboleth or something similar.
You should try that package : https://www.npmjs.com/package/ad I'm not sure it will meet your requirements, but it's a very easy t work with Active Directory in a node/express back end.
I'm building a new Web API application using OWIN cookie authentication (ASP.NET Identity 2.2) for security.
I'm new to the whole cookies thing, but I've got a head-scratching problem: How is a logged-in user immediately blocked from using the API if their account has been deactivated (either deleted or locked-out)?
This arises after a startling discovery that if I have a user logged in on a client app, and I delete their user account via a different app, they are still able to access the API (i.e. the [Authorize] filter still succeeds because their cookie is still valid).
Somebody please correct me if I'm wrong, but AFAIK, cookies are not stored on the server, so there is no way to "invalidate" the cookie.
Yes, if the user logs out, they won't be able to log back in again. Also, I understand that setting an expiry on every cookie upon successful login will mitigate the problem.
But what about the following scenario: a system administrator (let's call him JoeAdmin) gets fired or otherwise becomes untrusted and some other administrator locks out his account. If JoeAdmin happened to be logged in when he got fired and became disgruntled, he still has access to the system and can do some real damage.
In this scenario, how could JoeAdmin be blocked immediately?
JoeAdmin happened to be logged in when he got fired and became disgruntled
Also JoeAdmin could have saved the cookie value offline, awaiting for his account to be revoked, and then later restores the cookie value to his browser.
OWIN cookie authentication is not ideal if you ever need to immediately invalidate logins.
This is because all the state information about the user is stored client-side, authenticated with a secret only on the server-side.
That said, you could do something with Oauth2 refresh tokens like here. e.g. have an access token that expires after say a minute, which when expired the application has to use a refresh token in order to gain an access token for another minute.
This way, any revoked accounts are only exposed for a short time. However, you may need to deal with the complexity of out-of-sync clocks on client and server.
Long story short, if you need to secure your system in this way, traditional server-side tokens would be the way to go. They are more secure in this regard.
The risks with using OWIN cookies are very similar to those of using JWT's for authentication. See this comment and the associated question and answer.
I have been through much of the documentation and examples provided, but Im looking for some inputs for my setup from other users.
I have a some clients (website, iOs/Android apps). These only serves as a shelves and its content will be requested through servicestack, which makes servicestack a central point of my setup.
The client will login through servicestack and get a sessionid.
My question here is, how should i setup servicestack to make sure that the user is validated on each request?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted). Then on each request based on the session id, i check the cache to see if the user exists. If the user exists, the request i authenticated, and if not the user have to login again.
Am i on the right track here, or is there an easier way in servicestack, to support this?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted).
It sounds like you can just use the Authentication/Authorization plugin. Once a user is authenticated (using any of the 'Providers') the user's session is stored in the cache using the key 'urn:iauthsession:[sessionId]' and contains a bool property isAuthenticated. For any Service the requires Authentication you can use the Authenticate attribute.