@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!

@elciok

There is currently no way to determine if someone has gone through step-up auth via the token. I did just add an issue: https://github.com/FusionAuth/fusionauth-issues/issues/1491 feel free to add comments there.

What you can do is use a JWT populate lambda to add a claim to the JWT if the user has any MFA methods enabled. When you do a step up you'll get a token and you can look at that claim.

HTH

@admin-3

I think so. See the "Managed domains" configuration in the SAML v2 IdP.
https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/#create-a-saml-v2-identity-provider

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

@alex

Thanks for the additional information! It sounds like this is already an active issue that you can upvote for consideration into future versions of FusionAuth.

https://github.com/FusionAuth/fusionauth-issues/issues/1335

If a good workaround comes to mind, I will be sure to let you know.

Thanks,
Josh

@chrissmueller328

There is some discussion of this (mostly focused on SAML, but OIDC is referenced and considered as well)

https://github.com/FusionAuth/fusionauth-issues/issues/566

I will review further and see if the team has any other thoughts.

Thanks,
Josh

@rekhas-fahrizi

Can you provide a few more details about the request you are making (maybe a few code samples would be helpful as well)?

Thanks,
Josh

@andrew-boyd

Perfect! Sounds good1

Josh

First, we recommend a webview or system browser. They have different strengths. The system browser is recommended by the security BCP and is preferred if the mobile app is not built by the same development organization as is running the identity provider (FusionAuth).

However, if both mobile app and IdP are owned by the same organization, a webview is fine too, and can offer more control over the user experience.

That said, some folks, as mentioned in the question, don't want a webview. They want to build the login experience out of native UI components. This gives them full control:

In that case, there are a few consequences:

the Authorization Code grant is not possible to implement, because it requires the user authenticate at FusionAuth. You will be re-implementing all of the "hosted login pages" logic and flow using the API. See https://fusionauth.io/docs/v1/tech/core-concepts/integration-points/#hosted-login-pages for the list of functionality you should be prepared to re-implement. Your mobile app will see username and passwords. Prepare for that from a security perspective. You will need to choose between the password grant and the login API

These are functionally equivalent. Arguments in favor of the Login API:

Richer response (you get different status codes for things like MFA required or "user not registered to this application") Can be protected with a tightly limited API key. You could actually provision an API key per mobile device if needed, using the API key API and some custom code: https://fusionauth.io/docs/v1/tech/apis/api-keys/

Against:

You must embed an API key in your application or relax certain security settings Tightly couples your application to FusionAuth

Arguments for the password grant:

It's an OAuth grant, so code written against it is more portable. No API key needed. No security requirements need to be loosened.

Arguments against:

You'll have to be prepared to parse JSON in the response if you are in any exceptional cases (MFA enabled, etc).

HTH.

@joshua
Thanks. I've up-voted a few of those open issues.

Since I'm trying to make this work for a COTS application I don't have the luxury of injecting another API call.

For now I'm pretending that the groupId being returned is the LDAP distiguished name for the group (I prefixed it in the Lambda with dn=). Then I can trick the application to looking up the group by the LDAP dn instead of name.