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: Getting custom information from the hosted login pages into the JWT
This is not available today without some glue code.
Currently our suggestion is to use Javascript on the Login page to jam the claim into a meta field that is shown on a Webhook payload, like jamming stuff into
event.info.deviceDescription
.Then you create
user.login.success
webhook, making sure it is transactional. On login, the event is fired that off to your system and then you extract the claim off theevent.info.deviceDescription
field and make aPATCH
call to FusionAuth. In thatPATCH
call, you add this to a field onuser.data.x
.Then once that
PATCH
is successful, the200
response back to theuser.login.success
event which completes the login and triggers the JWT populate lambda. That lambda extracts the claim off theuser.data.x
field and puts it into the JWT.It's not pretty but it is the only way to have this work for now. (For self-service registration you can use a custom hidden field, much easier.)
Relevant docs:
-
Getting custom information from the hosted login pages into the JWT
How can I add in custom claims in to the JWT based on a custom login field or other parameters on the login form?
I have a parameter/variable that can change between each login (like a device id) and want it to be in the access token.
-
RE: allow users to register for any application but not create user accounts
This is possible in a couple of ways.
First, to allow users to register for an application on login, you need to turn on self-service registration. From the docs:
When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.
Then the question becomes, how can you disable the hosted login pages self-service registration form?
To do so, take the following steps:
- update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with
not implemented
or similar. However, a sinister user may still be able to post to theregister
endpoint and create a user - if you are self-hosting, block access to the
/register
endpoint using a proxy - if you are not self-hosting, prevent self-service registration by adding an encrypted secret value to all user accounts you create via the API. Then, create self-service registration validation lambda which will examine the
user
object. If the user object comes through without the secret value, fail the registration. Otherwise allow it through because it is a user who has logged in.
The self-service lambda may not fire unless there are required fields on the registration form, but that behavior is undocumented and may change.
- update your theme to remove the link to the "Don't have an account? Create one" link from any pages, including the login page. You can also remove all the content from the registration themed page and replace it with
-
allow users to register for any application but not create user accounts
I want to allow users to freely be registered to any number of applications simply by logging in, but not be able to use the self-service registration form to create user accounts (so I don't want them to be able to use the self-service registration form provided by the hosted login pages).
I'll create all user accounts using the User API.
Is there any way to do this?
inspired by this github issue
-
Docs now fully downloadable in LLM friendly format
If you go look at https://fusionauth.io/docs/ and scroll to the bottom, you'll see a new section called 'Download docs'.
This takes you to fusionauth.io/docs/llms-full.txt which is all of our documentation (5MB!) in one file so you can upload it to your favorite LLM and query it.
Hope you all find it useful.
-
RE: Does FusionAuth support mutual TLS?
By using a proxy or gateway that supports mutual TLS, you can use it with FusionAuth.
For example, AWS ALB supports
Mutual TLS verify
where the ALB does client certificate verification. Nginx has similar functionality.If you are running FusionAuth 'bare' and terminating TLS directly at the FusionAuth server, mutual TLS is not supported.
-
Does FusionAuth support mutual TLS?
Hiya,
Does FusionAuth support mutual TLS where the client and server both have certificates?
(I'm not talking about mTLS token binding; I understand that is not implemented per https://github.com/FusionAuth/fusionauth-issues/issues/1025 .)
-
RE: Does FusionAuth support mTLS token binding?
Hiya,
There are currently no plans to support the full mTLS spec. We are discussing DPoP (tracking issue) internally.
However, depending on your needs, there may be a workaround.
Since the client credentials grant depends on Entities, you can leverage this to inject a client certificate hash into an access token obtained through the client credentials grant.
How this works at a high level:
- Client Certificate Registration
During onboarding, your customer (e.g., a bank) registers their client certificate. A hashed value of that certificate is securely stored in FusionAuth (entity.data). The hashing process is outlined in the RFC. - Client Credentials Request
When the bank requests an access token using the Client Credentials grant, a FusionAuth Lambda is invoked before the JWT is signed. - Augment Custom Claims
The Lambda code looks up the stored certificate hash and injects it as a claim in the JWT. For maximum compatibility with RFC 8705, it is recommended to add this hash to thecnf
object in the JWT, like so:
"cnf":{ "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" }
- Accessing the Resource Server or API
The customer presents both the access token and presents their client certificate when calling your API. - Validation Flow
Your API:- verifies the JWT signature
- computes a hash of the presented client certificate
- compares it to the x5t#S256 claim in the token
- Decision Logic
If the hashes match, the request is bound to the correct client and access is granted to the protected resource.
- Client Certificate Registration
-
Does FusionAuth support mTLS token binding?
Does FusionAuth support mTLS token binding (RFC 8705, section 3) for the client credentials grant?
I found this issue but wasn't sure what the current status is: https://github.com/FusionAuth/fusionauth-issues/issues/1025
-
RE: How to deal with sign-up spam?
@theogravity-sb Hmmm. So the issue is that someone is registering with a gmail account they control but it looks like this:
foo@gmail.com with a name of <Dan https://evil.com> which is being turned into a link?
Or am I misunderstanding your question?