What are the security implications of storing a user's unique ID in a cookie?
Logging-in is managed separately. The presence or abscense of this cookie is simply used to determine:
Is this a returning user?
If so, who did this user last login as.
These are all merely hints, the user doesn't get any more rights (before login) than a first-time visitor to the site.
Background
My web app front-end is implemented in Angular4 and backend is all APIs and stateless. JWTs obtained from Firebase Authentication are used for authentication. As such, when a user arrives on the home page, I have no way of knowing who the user (potentially) is and whether they are logged-in, till the time the user goes to the PWA (at /app).
When the user goes to the home page of my web app, I want the (stateless) server to be able to redirect them to the PWA if they have logged-in in the recent past (say 2 days). This can be achieved simply by the presence/ absence of a cookie, but I would also like to be able to show them a personalised greeting when /app page loads up.
Very open to suggestions for a better way to achieve this.
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'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.
I have a tricky problem, i have got a Marionette Application based on a node.js backend which uses express-resource to access the database.
I use a middleware to ensure a logged-in user, if not the user is redirected to a login page which is served by node directly. After login the user has got a session cookie and is forwarded to the Marionette App.
The application doesnt know the user. In order to get the user i wil have to get it via an ajax call. The problem is, i don't know the users id because the session token doesnt contain this information.
My solution is: There are two resources in the api, one to get accounts in general and one to get only the current user. This is a kind of duplication of resources i want to avoid.
How to do this properly?
you can simply add the user id to the session cookie..
btw - make sure your backend accesses only the authenticated user's resources (according to the session) and that you don't have to provide the user id to AJAX calls. maybe you can actually avoid knowing the user id ?
I have developed simple website using Tomcat and Java. Now I'm trying to add authentication to it. I am storing username and encrypted password in database.
How do I validate user on every request to website?
While doing my research I found out that I need to set some cookie, return it to browser if user is authenticated, and then validate it request by checking this cookie in every request I get from user.
Also, how do I manage the session, i.e. create new session for user upon authentication, set timeout, clear session and cookie upon logout?
Web development and particularly authentication/user management is very new to me, so I will appreciate your help.
Thanks.
This will depend a lot upon the language you are using to develop the website and how you plan to handle sessions.
PHP Sessions
Java (JSP) Sessions
ASP.NET Sessions
ASP Sessions
...etc
the list goes on, especially with how to manage authenticating.
The general (pseudo code) for this usually revolves around something of this nature
Depending on the language of course:
User Creates Account (typically an HTML form posting to your server side code)
Account Information Is Stored to the database
Cookie is created with information allowing user to auth in the
future (with cookie duration)
Session is created for the duration of the users login
User leaves the website
User comes back to the website
Website checks for stored cookie
if Cookie is found - check cookie, is the auth still good? (did the
users password change recently? has the cookie expired)
If the cookie is good - create a new session and allow the user into the website
If the cookie is bad - present the user with a login form
Rinse/repeat as the user logs in and out.
Depending on your language you will want to look at different resources, however cookie generation is a pretty simple task and can be easily done with JavaScript and HTML. Take a look at http://www.w3schools.com/js/js_cookies.asp and see if it meets your needs. Note that from what I recall JavaScript only does Cookies, and not sessions.
I've written a web application that interfaces to an API, in a different domain.
This API requests a username and password for certain calls (involving POST, e.g. to upload a photo to the API). For these calls the API uses https.
Is there a way I can store the username and password within the web app, so the user doesn't have to log in repeatedly each time they upload a photo?
Here's what I can think of:
The obvious way is to stick both in a cookie, but clearly that's a security hole, whether plaintext or hashed.
If it were a secure website, I could use a session ID: could I persuade the API owners to allow session IDs, or would that be impossible across domains?
Perhaps I simply have to ask the user to re-enter their username and password each time they make an API call.
Thanks!
If I understand your architecture correctly, your users are sending the API calls to a service running in a different domain. You are not a man-in-the-middle for this request, you are only providing the interface e.g. as a form-field in your web application. The user can send the API calls without you even knowing that he did.
In that case there is no way to implement this without storing some kind of authentication information in the browser (cookie, form-field, etc.) or have your users enter them for each request. They must come from somewhere and your server is not involved in the request.
What you can do is changing the architecture and start playing man-in-the-middle, like a proxy. Instead of just providing the interface, let the users send their requests to your web application instead of communicating with the service directly. Your web application adds the credentials and forwards the request to the service. The answer of the service will be sent to your web application, which can redirect it again to the user.
In this scenario your web application is responsible for authentication. Your web application adds the credentials to a request if the user sending the request was identified and has the required permissions. The credentials for the service are only passed from your web application to the service, they even can be kept hidden from the user himself.
Such a change has several implications of course. The load on your web application will increase and the logic will become more complex. Those trade offs must be considered.