and/or detect that the user was an IdP managed user?

In the reconcile lambda from the IdP (here's the docs for the OIDC lambda), you can set whatever data you want on the user.data field, so you could set user.data.idpUser = true. Then you can access that value from the self edit page freemarker template and decide to show or hide the password field.

I get that this isn't as straightforward as it would be if the original feature request was implemented 🙂 . But I think there's a path forward here that doesn't wait on that.

Elasticsearch access is not available for FusionAuth cloud deployments.

I would recommend running FusionAuth locally, which should display similar results as your cloud deployment for how the user and the entities are mapped.

Users can be deactivated and reactivated using the User API. The following FusionAuth documentation outlines deactivation (or soft-delete) and reactivation:

Delete A User (soft-delete them, don't hard delete them)

Reactivate a User

HTH

The ability to search grants for a user was a gap in our documentation. We have since released an update to showcase/describe the use case.

https://fusionauth.io/docs/v1/tech/apis/entity-management/grants/#search-for-grants

Your API endpoint call will look like below:

GET /api/entity/grant/search?userId={uuid}

Additional possible filtering functionality is documented in this feature request.

@fred-fred said in Custom theme deployment between environments:

It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.

Yes, that's what I'd recommend. You could have different API keys for each environment and have the script that promotes the theme pull the API key from a secrets store. Make sure you limit the API key to the themes endpoint.

You also might be interested in this post: https://fusionauth.io/community/forum/topic/1306/parameterizing-themes which indicates how you can have the same theme files point to different resources in staging/prod/dev/etc.

@omryc3 Have you tested the authentication tokens and seeing if the password policy applies to them? I'm not sure myself, but it should be an easy test to run.

It is not possible to have different password rules apply to users in the same tenant, since they are tenant level policies and apply to every user within a tenant.

You could have the users that you want to have no password expiration use OIDC to login against a third party server. (And that server could be a different FusionAuth instance.)

@markus-wild

Hmmm. A few more details would be helpful. Are you using the basic self service registration form? And the mobilePhoneNumber field? Or is it some other field that you are using?

What is the exception you are seeing? Where does it show up? What does the end user see?

Also, what version of FusionAuth are you using?

Thanks!

@maciej-wisniowski Thanks for your help. I was able to connect but had some trouble from then on. I will create an issue on github and see if official support can be added.

Is there a recommended way of running fusion auth on a clustered database?

@fred-fred

Hiya,

In addition to what @maciej-wisniowski suggested, if you have a paid license you can now have application specific themes (one theme per application; if no application theme is specified, it defaults to the tenant).

You can see how that works in the sandbox environment (sandbox.fusionauth.io). I believe that feature landed in 1.27.0.

You can buy a licensed edition here.

@engineering-0 Try this:

users = [] for user in User.objects.all(): user_data = {} ... encryption_scheme = "salted-pbkdf2-hmac-sha256" algorithm, iterations, salt, password_hash = user.password.split('$') salt = base64.b64encode(salt.encode('utf-8')).decode('utf-8') user_data['password'] = password_hash user_data['encryptionScheme'] = encryption_scheme user_data['factor'] = int(iterations) user_data['salt'] = salt users.append(user_data)

@trashmi13

Hiya. You can validate this token using any JWT library, as Id Tokens are valid JSON Web Tokens.

I'm not sure what language you are using, but here's an example for java using the fusionauth-jwt library:

List<JSONWebKey> keys = JSONWebKeySetHelper.retrieveKeysFromJWKS("https://www.googleapis.com/oauth2/v3/certs"); Map<String, Verifier> publicKeyVerifiers = new HashMap<String,Verifier>(); for (JSONWebKey key : keys) { String publicKey = key.x5c.get(0); Verifier verifier = RSAVerifier.newVerifier(publicKey); // assuming all keys are RSA. You could switch on type as well. String kid = key.kid; publicKeyVerifiers.put(kid, verifier); } // Verify and decode the encoded string JWT to a rich object JWT jwt2 = JWT.getDecoder().decode(encodedJWT, publicKeyVerifiers); // make sure the aud and issuer are as expected if (jwt2.audience.equals("gge44ab3-027f-47c5-bb07-8dd8ab37a2d3") && jwt2.issuer.equals("www.acme.com") && (jwt.expiration.toEpochSecond() > (System.currentTimeMillis()/1000) )) { // valid id token }

Hope this helps.

Seems like a bug, filed an issue: https://github.com/FusionAuth/fusionauth-issues/issues/1503

@classbazaarco

What are you seeing in the event and error logs for FusionAuth?

https://fusionauth.io/docs/v1/tech/troubleshooting/#logs

Also, linking some additional doc here - https://fusionauth.io/docs/v1/tech/guides/silent-mode/#overview

Thanks,
Josh

Yes. A user can have one-to-many refresh tokens per application.

@justinfox Sorry for your frustration. Here is an angular app blog post and the authentication flows.

https://fusionauth.io/blog/2020/03/31/how-to-securely-implement-oauth-angular/

https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/

@mikko-koskinen This is probably a better question for the sales team than the community forum.

I'd suggest reaching out to them at https://fusionauth.io/contact/

The short answer is however often you want, but at least once per device.

You basically can set up your refresh token policy to have your refresh tokens live for a very long time (as long as you are comfortable with the security risk; make sure to secure the refresh token carefully). That is controlled in in the application configuration: https://fusionauth.io/docs/v1/tech/core-concepts/applications/#jwt

Then, every time an access token expires, you can mint a new one with the refresh token. Here are the APIs you'd be interested in calling:

https://fusionauth.io/docs/v1/tech/apis/jwt/

@elliotdickison

We typically see the chokepoints for FusionAuth in either the CPU (when doing a lot of password hashing) or the database.

More here: https://fusionauth.io/docs/v1/tech/installation-guide/monitor/#load-testing

Since usage varies, I suggest you perform your own load testing to determine connection limits. Would love to see your conclusions!