@harish_reddy I just want to make sure I understand where you are coming from. If you user signs up with an email address, you want the same response even if they are already signed up? Can you please share some images of how you would like the flow to work? I think this could cause problems and confusion the way I am thinking about it.

Hiya @benjamineroommen ,

I'm not sure what you mean? Are you talking about the JWT generated for a login event?

If you are using email verification, you can check this user state within your own app. (So, don't allow the attacker to access anything until their email address has been verified.)

In version 1.27.0 you can configure a gated login flow when the user is not verified (this is a 'reactor' feature requiring a paid license). This will enforce email verification before we even redirect to your app. You can then also configure FusionAuth to delete users after N number of days if the user has not verified their email address. This can assist with build up of accounts that are not actually in use.

Hiya,

PKCE is great and should be used if supported. This helps prevent authorization code replay attacks, as recommended here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#page-6

Using a proxy and storing the access token on server side rather than javascript solves a different set of security concerns. Because access tokens are typically bearer tokens and are not sender constrained, anyone who gets them has access to whatever they grant access to.

This means that if your javascript has access to the token, so does any other javascript running on your page. If you are comfortable with that (you've audited all the javascript in all the libraries, and their dependencies to ensure that there's no security issues) then storing the access token may be ok.

Since that level of comfort with javascript libraries is not typical (do you know what is going on in the dependencies of your dependencies? many folks don't), we recommend one of two approaches:

store the access token server side, and use the session to tie the client to the access token (what our blog posts typically do) store the access token in a secure, httponly cookie, so that it is not accessible to javascript, but is sent to any APIs. That's more fully fleshed out here: https://fusionauth.io/learn/expert-advice/authentication/spa/oauth-authorization-code-grant-jwts-refresh-tokens-cookies/

Of course, you alone know your security posture and what you're comfortable with, but that's what we recommend.

Officially we don’t require anyone to upgrade. However, generally speaking we don’t back port patches, this means if you need a fix you’ll have to upgrade to get it. There are a lot of good reasons to keep a security product up to date.

But when you pay for an edition of FusionAuth that includes support, you can run whatever version you want (more or less).

We have Breached Password Detection (in the paid edition) as well as brute-force login detection.

We have some other related features on the roadmap for 2020.

If you'd like APIs to automatically log to the audit log, without additional calls to the Audit Log API, please vote for this issue: https://github.com/FusionAuth/fusionauth-issues/issues/507

This may be useful if what you are trying to extract is in ElasticSearch (user data): https://elastalert.readthedocs.io/en/latest/

Doesn't help with other aspects of the system, but I believe we have some features planned.

There are a few ways to do this.

This assumes that you are running elasticsearch on a different server than you are running the fusionauth instances. If they are on the same server, you should be fine, as that is the default configuration.

The first is at the network level, using a firewall or something like security groups on AWS. If you are doing this, you can configure the server that elasticsearch is installed on to accept requests only from the server that FusionAuth is installed on.

The second is to use basic authentication. That is, set fusionauth-search.servers in the fusionauth.properties file, or the FUSIONAUTH_SEARCH_SERVERS environment variable to include the basic username and password. https://user:password@example.com. And make sure to set up elastic to use basic auth, using whatever authentication source you'd like. (You could even go meta and have elasticsearch auth the user against the fusionauth instance 🙂 ).

Further discussion here.

The way most of our clients handle this is by using proxy redirect rules. For example, if your service is available at https://auth.example.com then you would redirect https://auth.example.com/ to https://example.com to push the user back into the "user" space of your site. This would mean that if you have a FusionAuth admin, they would need to directly access the UI by navigating to https://auth.example.com/admin/.

If you're already using a load balancer or a similar technology that provides routing rules, these are easy to configure.

You can also use managed IP locking (limiting access to a certain set of IP addresses), or some other type of HTTP header on the request to limit access to the FusionAuth admin UI to authorized users and treat all other traffic to anything under /admin for end users as an invalid request. These types of solutions are best handled at the network layer or with a proxy.

Hiya,

When you say

Everybody can see authorization key.

Who do you mean? Do you mean anyone with access to the FusionAuth admin console? Or some other set of users?

Not currently. We've discussed it and haven't ruled it out.

However there are so many products, both free and commercial, that do this well.

You can always put a firewall on the server that FusionAuth is running or put a proxy in front of it.