Flask session is nothing but a signed cookie which stored in the client-side. By looking at https://stackoverflow.com/questions/22463939/demystify-flask-app-secret-key I feel like flask sessions can work without storing them anywhere in the server. Is that the case?
If so, can someone explain the fundamental difference between Flask sessions and JWT?
Related
I'm looking for some clarity regarding security concerns with just JWT in our current project.
basically it is working right now like this:
User authenticates with username + password at an authentication Service
frontend gets JWT
frontend can use this JWT in the communication with the backend.
but that seems unsecure for many reasons, so we discussed this so far and had a few ideas to make it more secure:
additionally encrypt the JWT, basically make an nested JWT (JWE) and work with a blacklist on logout... but here the question remains why work with an JWT and not a stateful authentication like Shared Sessions and a Redis service
Implementing an Api-Gateway so that the frontend or User gets a Session cookie and the gateway works with JWT for backend and auth. unfortunatly i've found no implementation like this whatsoever
We just want to be kinda secure in Login/Logout AND be scaleable in the the future so that there might be X other backends.
apologies for any errors, english is not my first language and i'm happy to answer any questions regarding this.
take care.
You are right that keeping tokens on the front end has some security issues. The current best practice is to try to keep tokens out of the browser altogether. At Curity we have described one possible solution as the Token Handler pattern. It adds a bit more complexity to your system but enables you to use secure sessions on the front instead of any tokens. We have provided a few implementations of the components needed by the Token Handler, you can have a look at how to run our complete example here: https://curity.io/resources/learn/token-handler-spa-example/
As to your first idea, if you want to implement blacklisting tokens, then you're in fact implementing sessions, and you're better off with cookies and plain old HTTP sessions. JWEs protect the contents of your token but an attacker can still steal such a token and use it to call your APIs.
I am mid-way of implementing oidc/pkce implicit authorization flow in my asp.net core rest web api for a public JS client.
I almost understand how this works, but I can't exacly understand what are the biggest issues with another approach - if I were to use the default cookie (or session) authentication provided by ASP Identity.
I find it hard to google this topic. Can I please ask for some hints / pointers to articles?
Plain cookie authentication is still used, even when you use token based authentication.
After the OpenIDConnect client receives the final tokens, it will by default create a classic session token that contains the user details and claims. Optionally you can also store the ID/Access/Refresh tokens inside this cookie.
The cookie is encrypted so it can't be tampered or hacked.
The benefit of using OpenIDConnect is when you have multiple clients and/or API's involved and you want a standardized way to handle this. Doing the plain cookie approach with many different services is hard to make secure.
Here is what my project structure look like
UI: AngularJS app
Backend: Java + MongoDB stateless app
The UI authenticates a given user and the REST api responds with a JWT token. For every subsequent request, the REST api expects token in the header and if its not there it returns Unautorized error.
Now, what is best way to implement logoff feature ? One thing is clear that i will be deleting the token from the UI cookie. But I need to tell server that the user has logged out.
I was thinking to maintain an in-memory db to keep track who has logged in and remove the user from memory once he is logged out BUT it would make the app some sort of stateful (I guess). Also, it could become complicated to scale the app since i would have to replicate the in-memory users across all nodes.
For every REST call, I am fetching the user-details from MongoDB. Would it make sense to use the DB to store the logged in status ? I am just thinking out loud. Since i don't know what directions to head.
If you are using JWT's to maintain sessions client-side, then the server should have no concept of logged in and logged out users.
This is the price you pay for deciding to use JWT's (which may be fine of course, depending on your risk appetite for the application).
If you wish to log users out server-side, then you should scrap the JWT model and record sessions server-side. That way you can delete the server-side record as well as the cookie on logout.
I use Play in a cluster behind an AWS load balancer. To prevent CSRF attacks I added #CSRF.formFields to all form submits. But I get 403 errors randomly, and I guess it's because the token issued by server
A wouldn't be accepted by server B.
Have you encountered this problem before? Did you need to store the session in a distributed cache or database? Are there features in Play that I'm not aware of that can solve this problem?
By the way, a similar question was asked here with no answers.
Thanks for your help!
try put this in your application.conf
trustxforwarded=true
or check your loadbalance configuration, maybe here You will find some usefull info
https://www.playframework.com/documentation/2.3.x/HTTPServer
As far as I understand, "application secret" is an attribute of an entire application, not a single instance/server.
Therefore it should be the same on all servers in a cluster. This will naturally "fix" the CSRF token validation.
As another example - sessions: by default session data is stored on a client side in a session cookie, and session cookie is signed using the application secret as a salt - if it would be different on different servers of same application - this would defeat the entire idea of the client-side session because session cookie would be only valid on one server.
P.S. Similar thread about Django's secret key: Django SECRET_KEY in a distributed setup
I am currently working on a website built with Backbone.js. The site has a RESTful API built in Symfony with FOSRestBundle. Developing was going fine, until I stumbled in to some user-related tickets.
From what I understand, the best way to handle this type of problem is with a token based system, where the user gets an access token after an approved login. I will describe my current perception of the workflow, and ask questions along the way. More importantly, please correct me if I have misunderstood.
First, the user the accesses the login form, then the user types in credentials, and an AJAX request is send to the server. From what I understand this should all be handled with SSL, but with Backbonejs, you can't simply say that the login page should be accessed with HTTPS, as Backbone is a one-page framework. So will this force me to use HTTPS through out the application?
In the next step, the REST server validates the credentials, and they are approved, then the REST server sends an access token to the client. Is this token saved (on the client-side) in local storage or a cookie?
Also is the login stored at the server, so that the REST server can log the user out after a certain amount of time?
Now, the client sends this access token along with other request, so that the server can identify the client, and approve the request or not. So the access token is also stored on the REST server?
Lastly is this what the smart people call "oauth", or does it relate to it?
Thank you.
Let's take your questions one at a time.
From what I understand this should all be handled with SSL, but with Backbonejs, you can't
simply say that the login page should be accessed with HTTPS, as Backbone is a one-page
framework. So will this force me to use HTTPS through out the application?
Ok, there's a lot to unpack there. Let's start with SSL/HTTPS. HTTPS is a protocol; in other words it defines how you send packets to/from the server. It has nothing whatsoever to do with whether your application is single or multi-page; either type of site can use either HTTP or HTTPS.
Now, that being said, sending login info (or anything else containing passwords) over HTTP is a very bad idea, because it makes it very easy for "bad people" to steal your users' passwords. Thus, whether you're doing a single-page or a multi-page app, you should always use HTTPS when you are sending login info. Since it's a pain to have to support both HTTP and HTTPS, and since other, non-login data can be sensitive too, many people choose to just do all of their requests through HTTPS (but you don't have to).
So, to answer your actual question, Backbone isn't forcing you to use HTTPS for your login at all; protecting your users' passwords is forcing you.
In the next step, the REST server validates the credentials, and they are approved, then
the REST server sends an access token to the client. Is this token saved (on the
client-side) in local storage or a cookie?
While any given framework might do it differently, the vast majority use cookies to save the token locally. For a variety of reasons, they're the best tool for that sort of thing.
Also is the login stored at the server, so that the REST server can log the user out
after a certain amount of time?
You've got the basic right idea, but the server doesn't exactly store the login ... it's more like the server logs the user in and creates a "session". It gives that session an ID, and then whenever the user makes a new request that session ID comes with the request (because that's how cookies work). The server is then able to say "oh this is Bob's session" and serve the appropriate content for Bob.
Now, the client sends this access token along with other request, so that the server can
identify the client, and approve the request or not. So the access token is also stored
on the REST server?
If you're running two separate servers they're not going to magically communicate; you have to make them talk to each other. For this reason your life will be easier if you can just have one (probably REST-ful) server for your whole app. If you can't, then your REST server is going to have to ask your other server "hey tell me about session SESSION ID" every time it gets a request.
Lastly is this what the smart people call "oauth", or does it relate to it?
Kind of, sort of, not really. OAuth is an authorization standard, so it's sort of tangentially related, but unless your login system involves a whole separate server you have no reason to use it. You could use OAuth to solve your "two servers, one REST-ful one not" problem, but that would probably be overkill (and regardless it's outside the scope of what I can explain in this one Stack Overflow post).
Hope that helps.