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?
Related
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.
I want to use Okta to safely store my users names and passwords; however, they also have information such as (to be general) age, birthday, graduation date, interests, etc. to be stored as well.
The Okta API does not store this info so upon account activation I need to create an entry for this user in my MongoDB database immediately.
Is there a way to detect this event? Thanks!
If this is extremely roundabout I am totally okay with taking a new approach too; however, I don't see much wrong with my current method if it is in fact possible.
I am using Node and ExpressJS to communicate with Okta using express-session and the oidc middleware.
A common solution would be to separate the user profile data from their credentials. So first, you have a user create an account or sign in with Okta. After they are signed in, you retrieve their profile data. If the user has no profile data in your webapp, you force the user to fill our their profile before they can use the webapp.
New user flow would look like this:
User clicks on "create account"
User enters in email/password in Okta
Your backend stores the user session
Your backend attempts to locate a user profile for the user. None found (first time user), so it restricts the routes the user can access.
Your frontend forces the user fill out the profile before accessing any other screens
User fills out profile and submits
Frontend POSTs profile to backend, backend saves it
Frontend and backend lift all restrictions, app continues as normal
I wanted to check with you guys if my API Key and user Authentication scheme makes sense or not. My server side code is in PHP and the Database is MySQL. This is the scheme I have in mind:
I am implementing a REST API in a backend server that will be called by a Mobile App (for now). At this point, I only want known Mobile Apps to connect to this API. So I am using a one-time API Key that has been given to the Mobile App during installation. Every request from the App passes the API Key that my API checks before going further. This Key is stored in a Database table. This completes my API Key checking and seems to allow only known Apps from calling my APIs.
Next, I also have certain services after calling the API which only authenticated users are supposed to get access to. For this, the Mobile App logs in with a Username and password which is authenticated in the User table of my Database. If it passes, the server generates a User Token and passes it to the Mobile App. The User Token is also saved in the User table against that User. All subsequent requests from the App (which requires user authentication) passes this User Token which is checked in the User table in the Database for User Authentication. If the Mobile App logs out, this User Token is deleted from the User table. I also have provision to add "TimeToExpire" for this User Token which I will implement later.
I would be really grateful if you guys could tell me the following:
Does the above structure makes sense for App Authentication and User Authentication?
I am a little lost as to what will happen if I ever need to change the API Key (for whatever reason). Not sure how that will be sent to all the Apps. Google Messaging seems like one possible way to handle that.
For the App Authentication, does it make sense to keep the API Key in a Memcached object? Since all requests from the Apps are authenticated, I don't want to go to the DB everytime. And pros/cons?
Along the same lines, does it also make sense to have the User Token in a Memcached object as well? Pros/cons?
I'm developing a web application and I'm having difficulties in implementing a log in feature.
In my application, a user has to log in to add a new item(row to a database and corresponding user id is added to the newly created row). Also, the user can navigate to different pages in the application, which all requires the user to be logged in. So, once the log in is successful the user id can be stored in a cookie file to share it with all pages. But I realized that, an user after using his credentials to log in, can then alter the cookie file and change user id in the cookie to someone else's and then view confidential data of the another person. How to prevent this type of attack ?
PS: I'm using servlets and JSP for my app.
An approach would be to, instead of storing the user id in a cookie, store an authentication token in the session cookie; this token needs to be unique per user and very difficult to guess. For this you could hash and salt the user id to generate the authentication token.
For extra security, make sure that the token expires at the end of the session or after the user logs out.
It would also help to do this over HTTPS, so that your traffic is encrypted.
Here is a very good guide to web based authentication.
In my case, company B (domain B) hosts a portal, which has link to my web app (domain A). If user clicks on hyperlink on the portal to my domain, he/she should be automatically logged into my app.
Existing poilicies that i cannot change:
User also has the ability to log into my domain directly, without going through the portal by supplying user id/password.
Also, existing company policy for user provisioning is that even if user log through portal of company B, they first need to have a user account with my company. Hence, the user will have account with portal company and my company.
Given these constraints, my plan for is following to provide automatic login from the portal.
When the user logs in to the portal, the portal company will generate a temporary token (UUID) and attach it as a query parameter to the hyperlink to my web app. When user clicks on my web app's hyperlink, my web app will receive a GET/POST request on the server side for a protected resource. At the server side, my web app will over https (probably two way SSL) invoke a URL on the portal's side, passing the temporary token. The portal side responds with a user id. My web app will map the user id with user's credentials and create a session for the user and allow access to the protected resource.
When the user logs out of the portal application, the portal server will make an Https request to my web app at a prespecified URL to log the user out. Since it would be two way SSL, logout url is protected.
My questions are following:
Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard. As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations. I am hoping that the temporary token described above is sort of access-token.
Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again.
Is there a standards based approach to achieving the above scenario. In near future, my company is planning to support OAuth 2.0 and i want to ensure that the above scenario will not violate any OAuth standard.
You kind of like answered your question already. That "standard-based approach" is OAuth which a Standards Track already documented by IETF in RFC 6749 and has been adopted by many software entities. If you don't implement OAuth then you are not violating the standardisation rules, you will be violating it if you claim to have implemented OAuth authorization in your system which clearly you haven't.
As per my understanding, OAuth 2.0 leaves the validation of the access-token to the implementations.
Well, OAuth is a bit more complex than just generating an access token, there's an authorization grant request involved before you can request an access token. You could also expose a token refresh endpoint if the life span of the access token needs to be extended by the client. So, there's more than just access token requests involved in OAuth authorization process
I am hoping that the temporary token described above is sort of access-token
What's an access token? It is up to you how you implement an access token, the implementation details belong to you and nobody else. The only thing that you need to guarantee is that the access token represents the authorization issued to client and its scope, in other words, given an access token your system should be able to identify a client and the scope of this client...what the client is allowed to do, what resources the client is allowed to request. Be aware that OAuth defines clients which doesn't directly translate to users, it could well be a user, another system, component or app.
Once the user closes the portal browser, is it possible for browser to destroy the cookie. In this case, if user opens another browser later on, he/she should authenticate again
Absolutely, yes. This is not related to OAuth at all, it's up to the client what they do with the access token and how they store it. If your system issues a non-persistent cookie, then as soon as the user closes the browser then the browser session is destroyed and also the cookie. All modern web development technologies offer cookie management implementations such as JSP, ASP.NET, PHP, etc. So I would suggest to store the access token in a non-persistent cookie and have your authorization server inspect requests to all protected resources by checking for the authentication ticket/cookie (where the access token is) and validate the access token, if the access token (or cookie) is not present then reject the request since it is an anonymous request to a protected resource.
Hope it makes sense