Topics created by dan

The easiest thing to do is to store the value on the user.data object in the reconcile lambda, and then pull it off in the JWT populate lambda.

The JWT populate lambda will only be called if the authorization code grant is completed and an access token is generated, but you should be doing that in your application.

So what it looks like is:

user visits your application user clicks 'login' user clicks 'login with OIDC' user authenticates user returned to FusionAuth reconcile lambda runs, setting values on user.data user object is created JWT populate lambda runs, pulling values from user.data and calling FusionAuth APIs to add user to a group or grant them permissions on an entity user object is updated, user exists in FusionAuth

Yes. You can do this with the API:

curl -H 'Authorization: ...' https://yourinstance.fusionauth.io/api/webauthn\?userId=00000000-0000-0000-0000-000000000001 > out

Then remove the following:

id insertInstant lastUsedInstant tenantId

update the userId

And use the import call:

curl -H 'X-FusionAuth-TenantId: newtenantid' -H 'Authorization: ...' https://yourinstance.fusionauth.io/api/webauthn/import -H 'Content-type:application/json' -d '{...}'

Right now you cannot turn off CAPTCHA for certain applications to handle this use case.

There's an open GH issue to address this. Please upvote or share your use case on there if you have thoughts.

As of writing, there is no direct support for push notifications as an MFA method in FusionAuth. If you would like such support, please open a feature request with more details about your use case.

However, you should be able to build something that sends a code via a push notification. Here's how to do that. (This requires a Starter, Essentials or Enterprise plan.)

This illustrates how to do this using the hosted login pages; if you use the APIs, it's a slightly different workflow, as outlined in the MFA guide.

configure FusionAuth to require a phone number when the user registers set up your android or ios device to send back the device id when the app is installed tie the device id to the user's phone number in your backend system set up a generic messenger. The messenger will send a phone number and a message when an MFA challenge occurs. look up the device id from the phone number in your system use the appropriate service to send a push notification with the code have the user enter the code in the MFA challenge screen

As of 1.51.2, there is no way to do this. We keep track of the trusted devices and you can, with certain parameters, retrieve them using this API but there is no detail about a device that It doesn’t have any details that would allow you to revoke trust for a specific device.

If this is of interest to you, future reader, please open a github feature request with details about your use case.

See also this open GH issue addressing this: https://github.com/FusionAuth/fusionauth-issues/issues/2821

This is an example of Third-party Service Authorization.

We store the tokens on the Link, but leave the refresh operation up to the software needing to access the third party API.

This approach has some tradeoffs, but gives more granular control to the application that needs the access token.

How it works:

The developer sets up an 'authorize' button in their application We take care of the authorization/authentication/storage of the refresh token.

... time passes

When they need an access token, they call our APIs to get the refresh token for a particular user They call the 3rd party service to get the access token, They use the access token.

If the access token expires while they need it, they can get the refresh token again and then get an access token.

FusionAuth has a bunch of import scripts, but one that you are probably most interested in is the CSV importer, which takes a CSV file and then calls the user import API.

Here's the link: https://github.com/FusionAuth/fusionauth-import-scripts/tree/main/csv

Of course, LDIF is not CSV.

Instead of using a CSV gem to get the list of users and their attributes, use a gem that can read LDIF. Here's a candidate. https://www.rubydoc.info/gems/ruby-ldap/0.9.19/LDAP%2FLDIF.parse_file but I'm not sure what the state of the art for ruby LDIF parsing is nowadays.

If you pursue this, please submit a PR to that repo because there may be other folks who want to import users from LDIF

An alternative would be to have them manipulate the LDIF file into CSV and import that using the csv importer. See https://www.google.com/search?client=firefox-b-1-d&q=ldif+to+csv for some examples on how to do the LDIF->CSV transformation.

If this is isolated to one user it's happening to that's usually because the user is trying the flow across browsers or devices instead of completing the whole flow inside 1 browser.

For example, they might be requesting the Change Password on their phone but then open up their email on a desktop and click the link. Thus the desktop browser would be missing the CSRF token from the beginning of the flow.

This can also happen if they request it on Chrome, but click the link in the email in Firefox (or even Incognito/Private browser vs normal).

If it is more widespread (across many users) then it is probably something else, like a theme issue.

Hmmm.

Did some research and there's no way to straight forwardly have Discord delegate user management to an IdP.

This is in contrast that with other tools like Zendesk which let you do this pretty easily.

Of course, you can go the other way (have users log in with Discord) but that's not what you are asking.

There are some workarounds, but they require custom discord development. Here are some options:

Create a discord application that adds users to a server based on the oauth2 flow with the guilds.join scope. set that application up in a way that people need to sign in with FusionAuth and link that signup to their discord account. Your discord app that handles said oauth2 flow. Then you add users through that app instead of invite links. Use a public server but lock channels behind a role which gets added upon authorizing with FusionAuth by your bot. You could also use linked roles with a general access role people can opt into, if they fulfil the requirements set by that role (which you could control via registration at FusionAuth).

There's lots of documentation on creating discord bots but I don't have a specific example of any of these solutions, sorry.

I've tested on 1.50.1 and I am able to see the usernameClaim in the response body.

However, that field is something that is not set by default and will only show up if that field has a value in it, otherwise it will not be in the response body.

The hosted backend is designed to cover a number of use cases, but is not very configurable.

If you need more control over the backend, it's suggested you stand up your own application backend to do the token exchange and set the cookies or otherwise store the access token. Many frameworks will take care of this for you.

FusionAuth has provided a sample express application that has the same functionality as the hosted backend and can be extended. For example, to change the domain of the cookie set, you can modify the cookie setting code here.

The best way to solve this is to use a <meta> element with its http-equiv set to Refresh in the <head> of the page.

When the page is displayed, the browser will go the indicated URL.

The Verify registration complete template can be updated like this, for example:

[@helpers.head] [#-- Custom <head> code goes here --] <meta http-equiv="Refresh" content="0; URL=https://google.com/" /> [/@helpers.head]

@alex-3 I'm a bit unclear on what you are trying to do.

Can you outline the exact steps you want to take?

Thanks @dan 💮,

so in other words your saying to manage who invited who* in my own app; thing like keeping this data.

Now that I think about it this makes more sense since then I have more control over it and can change its implementation however I want in the future. Besides FusionAuth is all about Auth and not my business models 😅.

*Let's assume we have a referral program in place

This is possible today using a Google Reconcile Lambda. Our Lambdas allow arbitrary JavaScript to be executed during a login event. You can write logic to check the user's domain and assign them the appropriate role associated with the FusionAuth Application they're authenticating through.

Below is a code example demonstrating how you could implement such logic:

function reconcile(user, registration, idToken) { function extractDomain(email) { // Split the email address by '@' symbol var parts = email.split('@'); // Return the second part which represents the domain name return parts[1]; } // function to extract the email domain from the user object and stores in domain variable var domain = extractDomain(user.email); // Conditional statement checks domain for fusionauth.io and adds 'counsellor' role, if any other domain exist adds 'user' role if (domain === 'example.com') { registration.roles.push('teacher'); } else { registration.roles.push('user'); } //This is optional, but is good to have for debugging purposes. The results will be returned in the event logs. console.info(registration.roles); }

The best solution here would be to use entity management.

You can create an entity type of Session or similar.

Each time you have a user log in, you can create a Session and set the .data.session_identifier field to the value of the device fingerprint + business specific indicator, and store the access token as the value.

When you are trying to find whether a user has a valid session, you can use the Entity search APIs to find that key and get back the value. Or, if the value doesn't exist, the user has no valid session.

For expiration, you can use the access tokens exp claim (which means anything consuming it will have to check that, which it should anyway). You could also manage additional expiration metadata in the .data field if you needed different logic (you have 5 hour access on weekdays, 10 hours of access on weekends or something similar).

Note that you should be vary aware of the security implications of this scheme (for example, that the device fingerprinting is unique and that the access token is narrowly scoped enough that if it is somehow obtained by an attacker it can't be used to damage the system)

@ryan-hopper Thanks for sharing that info. Appreciate it!