Hiya,

This JWT is valid because the JWT is not expired. You can't revoke a JWT by logging out because they are stateless. Here's more information about how revoking JWTs: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts

This is one of the reasons why we recommend storing a JWT in a server side session, so that removing the session (on logout) removes the JWT. More here: https://fusionauth.io/learn/expert-advice/authentication/webapp/oauth-authorization-code-grant-sessions

Does that help?

There is not any way to push events from FusionAuth to a system like pagerduty, except those outlined by the webhook docs which are less system level and more app level.

If you are monitoring using systems like opsgenie, you can pull data from several different sources:

There's the system status endpoint, which can be polled. Before 1.19, it was binary (200 is good, anything else is bad) but now with 1.19 there are defined status codes: https://fusionauth.io/docs/v1/tech/apis/system#system-status This is the single best endpoint for a healthcheck. If you want to ingest system logs so they can be searched/scanned, you could set up a job to export the system logs: https://fusionauth.io/docs/v1/tech/apis/system#export-system-logs and process them (that that doesn't work for container based systems, see the docs for more). These logs are what you'd see if you were running fusionauth in docker and looking at STDOUT (so system level stuff). You can write your own scripts against the API to test for certain use cases ("Can this user login?", "Can this user register?") There's an event log which captures, well, system events, which can be accessed via the API: https://fusionauth.io/docs/v1/tech/apis/event-logs There is also the audit log, which is probably not what you are looking for, because that is less system level and more 'in app' events, with admin level actions being written (see also this issue). But it can be read via API: https://fusionauth.io/docs/v1/tech/apis/audit-logs

If you are running in Fargate, k8s or another container based system, your best option is to write something to pump the logs through a stream which you can then process for interesting/problematic events.

If you use the request body you should be fine. You can do a lot more than 500 if you like.

I would start with 5-10k and see how performance is.

@dan Yes, I am using the login API and the Identity Provided API. More specifically, the following routes: /api/login & /api/identity-provider/login. They both have similar response cookie functionality. Your explanation makes sense, however I do agree with the GitHub issue about this functionality being optional (or at least allow the developer to choose which response cookies they want to set). For the meantime, I suppose I'll just use the provided functionality as-is and look more into the mentioned alternatives if necessary.
Also, thanks for linking to the SameSite configuration. I'll take a look at it to see if it fits my needs.

Thank you for your reply!

Well, I'd just call the 'create registration' API from the server three times after a user had successfully registered on your custom page: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-registration-for-an-existing-user

Does that make sense, or do I misunderstand your question?

Are you using javascript in the browser to register the user? Or a server running node (or some other language). If the latter, you could send down an HttpOnly cookie based on the response of the registration.

You can also view some of the back and forth between @robotdan and I on the issue I filed: https://github.com/FusionAuth/fusionauth-issues/issues/878 🙂

Try adding mode: 'no-cors' to your request to see if that changes your result.

Also, make sure that application/json is the Content-Type header for all requests to the FusionAuth API, unless otherwise specified in the documentation.

Narrator: This resolved the issue.

Here's an example using flask: https://github.com/FusionAuth/fusionauth-example-flask-portal

You can see all the example apps here: https://fusionauth.io/docs/v1/tech/example-apps/

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 only publish keys that we can use for signing, so a public key all by itself will not be published via JWKS. If you import the entire key pair, it will be published on the JWKS endpoint.

You can also generate a keypair too.

You can use the database.maximum-pool-size value in the fusionauth.properties file prior to 1.19.x ( it was just not documented) , but if you want to use the environment variable version is not available until 1.19.x.

Is this what you are looking for?: https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined

That API does return a token as of v1.17.0.

Please feel free to vote for the issue @mehr-prs , if it is important to you. Here's the general FusionAuth roadmap guidance: https://fusionauth.io/community/forum/topic/172/the-fusionauth-roadmap

No worries.

Please upvote it if you are interested in this moving toward the front of the work queue.

Not really, at least not through FusionAuth interfaces.

If you have particular queries that aren’t working well, you can open an issue in GitHub or a support ticket: https://github.com/FusionAuth/fusionauth-issues/issues

I do not believe so. I just added a github issue for a similar issue: https://github.com/FusionAuth/fusionauth-issues/issues/874

Please feel free to upvote this if the issue describes your goals.

If not, please explain in more detail what you are trying to accomplish.

Not currently.

You could create a single user called anonymous and auth that user to get a generic token.

There is an open issue for a more elegant solution; feel free to upvote it: https://github.com/FusionAuth/fusionauth-issues/issues/525

No, the users must have a password. In this scenario, where you know the users do not have a password, you can just set a secure random password. A UUID, or other securely generated high entropy value.

You can provide the password value, but this will cause FusionAuth to hash it inline, so it will be costly in terms of time and CPU if you are importing a large number of users.

If you don’t want to take this hit at import time, you can provide these users just random hashed values, as long as you provide the factor, encryptionScheme, salt and password FusionAuth will assume this is a hash, and it will not re-hash it.