We have developed angular UI with MSAL authentication, in that one user is able to login to the application simultaneously from two different locations.
Is that any possibility to disable the concurrent logins in azure?
We can restrict concurrent user login process in 2 ways
Solution 1:
Enable multi-factor authentication (MFA) to enhance login security and reduce login risk. Once MFA is enabled, it could require the user who is logging in to confirm by using a phone call or text code after entering the user password. This will have the same effect as restricting multiple sessions for a single user.
Solution 2:
Capture the JWT token in the backend database and verify the user sessions via API calls.
For example:
The user logs in using device123, then saves the token in the database and sends it to the token in the API for use on the front end. If the same user tries to login with device 321, then the user will successfully login with the old token or place a condition and refresh the user session.
Related
I'm using azure app service built in authentication to log in users to my web app. Since I have some pages that user can access without authentication I have allowed anonymous access in app service auth configuration.
It works as intended for the current session. But when the user closes the browser or opens a new window, the authentication is lost. The user is required to login again.
Is there any way to keep the user logged in?
What I do currently:
On sign in button click,
direct the user to /.auth/login/microsoftaccount, after successful login I call ./auth/me to get the user claims/details and then login the user. Then I do a http post to https://appname.azurewebsites.net/.auth/login/microsoftaccount to validate the tokens that I got from /.auth/me and I also get a session token from this post request (which I don't know what to use for).
I use the custom headers set by the app service for authentication on the backend. App service auth docs
Is this the right way of doing authentication using app service. If so is there any way that we can keep the user logged in to app service auth and not ask them to sign every time they open the website.
Is there any way to cache the tokens?
It is normal that you need to login again after close your browser or open in a new window, because the life cycle of session is from opening the window to closing the window.
You could consider using cookie coordinating with session. Session is on server side, we cannot see it, but we could set the time out value. Cookie is on client side, we could save some authentication information to stay login, but it is not safe.
I am using Microsoft authentication for user but I don't want to keep the user credentials to be saved in cookies so that it should ask every time performing a particular action in application.
I have created a simple web app with external authentication from Microsoft but when a user gets signed in it doesn't ask user for credentials from second time and redirect to RedirectUrl directly because user information is already there in Cookies. Normally this behavior looks fine but I have certain tasks in my Web App which needs authentication from External Source (Microsoft) every time these tasks get performed by user. I tried setting token lifetime in Azure but it says lifetime can not be lesser than 10 minutes.
Note: I can't call signout user because it is not a silent signout.
How can I achieve it?
You can set prompt=login parameter in the authentication request. Then the user should be prompted to re-authenticate even if the user has already been authenticated.
Reference:
https://learn.microsoft.com/en-us/azure/active-directory/azuread-dev/v1-protocols-oauth-code#request-an-authorization-code
https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-js-prompt-behavior
I am trying a post-call to generate an access token using the client username and password. I would like to know how we can achieve this through Node Js Code.
Generally speaking, access_token are rattached to the OAuth2 authentication framework, which doesn't require the application owner (you) to have access to one of your user email/password. This is a more secure approach that is broadly adopted.
The way OAuth2 works on the Google Calendar API is a 3-parties (or 3-legged) authorization. Let's take the example of a user that browses your website and want to sign-in using its Google Account. The steps to authenticate him are the following:
The user clicks on "Sign-in with Google"
The application owner (you) performs a request to Google saying that a user wants to connect (that's the OAuth consent screen)
Google replies by giving you a URL (authorizationUrl) where to redirect the user
On that URL, the user is prompted with several information about your application and can grant access.
When the user has granted access, Google will redirect the user to your application success page (callbackUrl) with a unique code.
Using that code, the application can retrieve an access_token, which temporarly lets your application performs requests on behalf of a user.
These steps are a rapid overview of the OAuth-flow, also known as the OAuth dance. To make POST requests to the Google Calendar API, you will have to perform that OAuth dance for every single of your users.
Implementing that flow can be tricky. Fortunately, Google gives very helpful documentation on that. If you don't want to bother, you can also use API-tools (like Pizzly) that takes care of that for you.
I'm looking for a way to share SSO user table and secret key with other applications using Node.js API.
Current implementation: I have a central server which is used for Authentication. Authorization happens at the application level. A user signs up using my SSO server. The user information is stored in MySQL DB. when user logs in SSO will generate a JWT token, sends it to the client (stores it in a cookie). Then the client, for each request, will send the token instead of username and password.
I will have a product display page which will list all the applications.
Each of these applications has their own DB/file system to store user information. I thought about two ways to share the user information and secret key with each of these applications.
Design 1:
You copy the value of the JWT from a cookie, decode it in your application and then try to insert user information into the respective database/file
This operation happens in the product display page of SSO when a user clicks on a particular application
Every application won’t have user information stored unless the user clicks on App in the SSO product display page.
Design-2: Applies for both user management and a key share
We explicitly configure all the application servers in SSO
We provide an API to send the user data to the application
How do I efficiently manage to add, delete, update user information across multiple applications and share the secret key among all the apps? How should I approach it?
I have a Node.js application that offers several different routes in front of MongoDB. I need to make sure that only authenticated requests can access these routes.
Ideally, I want to set it up so that a username and password comes in to the API, and in a response we give them back a token. I don't mind managing the tokens inside MongoDB myself, but I need to make sure that the token we give back can make authenticated requests. I don't want to force the user to send their credentials each time, just the token.
I've read for a few days about passport, and there's currently 307 strategies. Which strategy am I describing here?
Which strategy am I describing here?
You are describing a Local Strategy.
As per their description:
This module lets you authenticate using a username and password in your Node.js applications.
I don't want to force the user to send their credentials each time, just the token.
Passport auth strategies just provide various ways to authenticate (or in simple terms login) the user, not how to persist that login. Login persistence is usually done with user sessions.
One way you can solve this is to combine the local strategy with the express session middleware. Combination of the two allows for a fairly simple auth system that requires the user to login once and then persists the session.
In a typical web application, the credentials used to authenticate a user will only be transmitted during the login request. If authentication succeeds, a session will be established and maintained via a cookie set in the user's browser.
Each subsequent request will not contain credentials, but rather the unique cookie that identifies the session. In order to support login sessions, Passport will serialize and deserialize user instances to and from the session.
PassportJS docs give an example how to achieve this.
For this you should prefer generating JWT tokens for a the login and then using the token to always authenticate user actions.
Following steps are need to implement this style of token login system
generate token on login
verify when token supplied and use the decoded data to identify user
use should proper middleware in order to protect your api.
Here is a link you could follow:
https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens