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: Client secret hashed in source identity provider
No perfect options, but a few workarounds possible
- a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash.
- stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course)
- go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)
More details on the first option. It requires these steps/prereqs:
FusionAuth Entities Setup
- The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret.
- Custom Attribute for Migration: Store a custom attribute such as
migration: false
onentity.data
for all newly created Entities.
Migration Steps
- API/Service Requests Token: The API or service calls Duende's token endpoint.
- Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID.
- Migration Check: Use an if/else logic to check if
migration: false
exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text). - JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set
migration: true
on theentity.data
object. - Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.
Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.
-
Client secret hashed in source identity provider
We're migrating from an identity provider (Duende) that hashes the client secret when the client credentials grant is used.
How can we migrate these secrets to FusionAuth entities?
-
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.