I'd like to update the user data object in the UI. I know I can do it via the API: https://fusionauth.io/docs/v1/tech/apis/users
dan
@dan
Head of Developer Relations at FusionAuth.
Enjoys ruby, java, php. Finds golang challenging.
Likes the authorization code grant, automation, stories and clear documentation.
Hiker, camper, gardener. Used to have chickens, now just tomatos.
Best posts made by dan
-
Is there a way to update user data in the UI?
-
Can I configure the inactivity timeout of the FusionAuth Session cookie?
I have a quick question about FusionAuth and configuring the inactivity timeout of the session cookie it creates. Specifically... Is it possible?
-
Terraform provider for FusionAuth released
There's now an open source terraform provider available: https://github.com/gpsinsight/terraform-provider-fusionauth
It's also on the registry: https://registry.terraform.io/providers/gpsinsight/fusionauth/latest
-
RE: Block authentication until user is verified?
Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?
Within a lambda, you have access to the user and registration properties. So you'd pull the
verified
property from wherever you wanted and put it into the JWT as a custom claim. Here's a blog post about how that might work.So yes, it is the same data. It's the tradeoff between a bigger JWT and having to make the additional call from your API.
Don't forget that the JWT will live for a while, so if this sequence happens and you use the JWT, you might have a user with a verified email prevented from using the API.
- user registers
- JWT issued, with
verified
set tofalse
because the user isn't verified. - User verifies their email
- User visits API, but is denied because the JWT has stale data.
I don't know timelines and how long your JWTs live for, but this is something to consider. Does that answer your question?
-
RE: My JWKS are always empty
Symmetric keys are not returned on the JWKS endpoint, as they don't have a public key. Per the docs this api:
returns public keys generated by FusionAuth, used to cryptographically verify JWTs using the JSON Web Key format
If you create an RSA or EC key which is an asymmetric key pair - the public key will be returned on the JWKS endpoint. If you don’t have any key pairs configured , it will be empty. Out of the box, you’ll only have one HMAC key which we don’t publish in JWKS.
-
RE: Implementing a Role-Based Access System for Authorization
Ah, I just tested this out and if you don't need it in the JWT, you should be able to see it in the registrations object returned after login.
Here's a response I get after logging in:
{ "token": "ey...", "user": { "active": true, "connectorId": "e3306678-a53a-4964-9040-1c96f36dda72", "email": "email@example.com", "id": "2df13f18-01cc-48a4-b97a-2ab04f98d006", "insertInstant": 1592857899119, "lastLoginInstant": 1596819645662, "lastUpdateInstant": 0, "passwordChangeRequired": false, "passwordLastUpdateInstant": 1592857899145, "registrations": [ { "applicationId": "78bd26e9-51de-4af8-baf4-914ea5825355", "id": "73d2317b-d196-4315-aba2-3c205ed3ccae", "insertInstant": 1592857899151, "lastLoginInstant": 1592857899153, "lastUpdateInstant": 1596813810104, "roles": [ "Role1" ], "usernameStatus": "ACTIVE", "verified": true } ], "tenantId": "1de156c2-2daa-a285-0c59-b52f9106d4e4", "twoFactorDelivery": "None", "twoFactorEnabled": false, "usernameStatus": "ACTIVE", "verified": true } }
So
user.applicationId.roles
is what you want. Note that roles are applied on an application by application basis. If a user is in a group which has a role 'roleA' which is created in 'applicationA', but is not registered for 'applicationA', they won't receive that role. More on that here: https://fusionauth.io/docs/v1/tech/core-concepts/groups -
RE: Trouble getting the user object post login
OK, we just released 1.18.8 and that is the version you want to use:
In
requirements.txt
:fusionauth-client==1.18.8
And then this is the call you want to make (with
client_id
beforeredirect_uri
) :resp = client.exchange_o_auth_code_for_access_token(request.args.get("code"), client_id, "http://localhost:5000/oauth-callback", client_secret)
-
RE: Specifying password during user registration.
Hiya,
First off, we'd recommend having all the flow you outline be over TLS. That's good enough for most major ecommerce systems and so shouldn't be insecure. If you aren't serving your application over TLS, then I'd advise doing so. And note that the flow is actually:
My Frontend
-->My Backend
-->FusionAuth API
There's no password returned from the registration API call.
If you are concerned about a new user's password being insecurely transmitted through your application, you could use the FusionAuth hosted login pages and theme them to be like your application. (More docs.)
The other option, which takes encrypted passwords, is the Import Users API, but that's probably not a fit for one off registrations. There are no plans to accept encrypted passwords for one off user registrations. Here's a related issue you can weigh in on/vote up if you'd like. Or feel free to open a new issue if that one doesn't capture the essence of your idea.
Are there specific security concerns you have around your front end/back end systems that I might be missing?
Latest posts made by dan
-
RE: Does FusionAuth work with resend, the email provider?
While I have not tested it, this documentation shows how to use an SMTP integration to send an email with resend.
This should work fine with FusionAuth's email settings.
-
Does FusionAuth work with resend, the email provider?
Does FusionAuth work with resend, the email provider?
-
RE: Compatibility of refresh token settings: sliding window and one-time use
It's a subtle difference, but one-time use refers to the value of the refresh token, which you use against the /oauth2/token endpoint to get a new access token via the refresh grant.
A sliding window refers to the refresh token itself, which has a unique id which stays the same, even as the value of the refresh token changes.
So if you had a refresh token with a lifetime of 4 hours, a sliding window and one time use configured, you might end up with something like this:
- at creation: id
09cfb961-291a-420f-b5cf-48c5c87a67cc
, valueRNhY5yE39t1o2FXKxgyH
, lifetime 4 hours - when the RT is presented to the /oauth2/token endpoint 3 hours after creation: id
09cfb961-291a-420f-b5cf-48c5c87a67cc
, valueFh95KZLfSMjMNxpR5B4c
, lifetime 4 more hours - when the RT is presented to the /oauth2/token endpoint 3 hours later: id
09cfb961-291a-420f-b5cf-48c5c87a67cc
, valuebaHneP4s0hBHPEk88GPC
, lifetime 4 more hours
More details here: https://github.com/FusionAuth/fusionauth-issues/issues/2925
- at creation: id
-
Compatibility of refresh token settings: sliding window and one-time use
If you have one-time use refresh token, then every time it is used, you get a new refresh token.
If you have a refresh token with a sliding window, every time you use it, its lifetime is extended.
How are these settings compatible?
-
RE: OAuth introspect endpoint works only with the credentials of the creator of the access token being verified
Also, why doesn't FusionAuth expose the default signing key, HS256, at http://localhost:9011/.well-known/jwks.json?
@fusionauth-qhj5e We don't publish the HMAC key to JWKS.json because if we did, anyone would be able to find it, and sign JWTs as your FusionAuth installation. HMAC keys should only be used when both parties can share a secret.
I'll update the docs to make that clearer. Sorry!
https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/endpoints#json-web-key-set-jwks
-
RE: Changes not being applied
@sspinn Hiya, I'm in the admin console pretty regularly and haven't seen this behavior.
Can you narrow down the replication steps so we can try to recreate?
Which version of FusionAuth you are running and what database you are using will also be helpful.
-
RE: Can you move users from one tenant to another?
Another option that works as of today is to set up a tenant to tenant connector.
Add a connector to the new tenant. Point it at the /api/login endpoint of the old tenant, including an API key as a header.
Change your app to send everyone to a new application in the new tenant.
When the user logs in to the new application, if it is the first time they've been seen, the old tenant data, including password, will be queried. The password hash will be transparently migrated to the new tenant.
This slow migration takes time, but is another option.
-
RE: Using react app auth and react native and getting access to the profile pages
Hi @jamesbaxter . Sorry, just saw this now. I don't have the example app available. Sorry!
-
RE: Editing user data in the UI
When I navigate to the Reactor page, it shows that it's licensed with a Community Edition license.
Custom form fields require a starter license, and because you modified the form field names, FusionAuth thinks you are trying to use a custom form field. (Note, I'm not suggesting you buy a license--this functionality should work in community edition--but I wanted to explain why you are getting the message.)
With the move to 1.53.2 did you upgrade or use a new instance? If the former, does the issue still appear in a new install?