Hey Eddie,

This doesn't appear to be a question about FusionAuth. We try to keep the forum on topic.

Thanks,
Dan

Hiya,

FusionAuth is only supported on mysql and postgresql. People have made it work on mariadb, but I think it'd be a large effort to port it to a nosql database like mongodb. There are no plans on our side to do so.

The system uses mybatis and I don't see any support for mongo at the mybatis website: https://mybatis.org/mybatis-3/

So, I'd say it is far beyond "extra tweaking" to make FusionAuth work with mongo.

No, this isn't currently possible.

I think that would fall into the threat detection bucket of features we are planning. Feel free to add any notes, comments or suggestions here: https://github.com/FusionAuth/fusionauth-issues/issues/905

It sounds like citibank is acting as the authorization server in this scenario.

You could look through the example apps we provide and pick the language you use. Then wherever we mention FusionAuth, you could instead slot in the citibank information.

If they support OIDC or SAML, you could also have FusionAuth delegate auth to them using by configuring citibank as an identity provider. A quick scan of the docs indicates they don't support those standards, though.

so my users can login

FusionAuth would be helpful in providing user management to your application and your users, outside of any interactions with citibank.

I recommend going through the 5 minute setup guide and kicking the tires yourself to get an understanding of what FusionAuth can do.

Cheers!

This data is exposed in version 1.20.1.

Once you make the purchase, you will be given a license id. You’ll enter that license id into your self-hosted FusionAuth under the Reactor menu item. This will activate your license and enable all of the premium features.

If you also purchase an Edition that comes with support, you’ll see a new menu item on your account in the FusionAuth website. This will let you open support tickets or provide you with our support phone number if you have an emergency.

FusionAuth doesn't support RADIUS at this time. Please feel free to file a feature request here: https://github.com/fusionauth/fusionauth-issues/issues

We do support LDAP through our connectors, a paid edition feature. More here: https://fusionauth.io/docs/v1/tech/connectors/ldap-connector/

Can you present the fusionauth access token to the fusionauth /userinfo endpoint and get back what you need?

Hiya,

PKCE is great and should be used if supported. This helps prevent authorization code replay attacks, as recommended here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#page-6

Using a proxy and storing the access token on server side rather than javascript solves a different set of security concerns. Because access tokens are typically bearer tokens and are not sender constrained, anyone who gets them has access to whatever they grant access to.

This means that if your javascript has access to the token, so does any other javascript running on your page. If you are comfortable with that (you've audited all the javascript in all the libraries, and their dependencies to ensure that there's no security issues) then storing the access token may be ok.

Since that level of comfort with javascript libraries is not typical (do you know what is going on in the dependencies of your dependencies? many folks don't), we recommend one of two approaches:

store the access token server side, and use the session to tie the client to the access token (what our blog posts typically do) store the access token in a secure, httponly cookie, so that it is not accessible to javascript, but is sent to any APIs. That's more fully fleshed out here: https://fusionauth.io/learn/expert-advice/authentication/spa/oauth-authorization-code-grant-jwts-refresh-tokens-cookies/

Of course, you alone know your security posture and what you're comfortable with, but that's what we recommend.

@dan said in JWT token with roles:

"applicationId": "ffbbef97-a2c0-49eb-990d-bd6e96acf2f9",
"roles": [
"USER"
]

Hey Dan!

Now we got it working.

For reference, we were not passing applicationId inside the request body, that's why the roles were not included in the token.

Thanks again for the time Dan!

Great, thanks a lot
I will indeed use a server-side function with an API token which will be called from the user.create webhook 👍

Double check that you are calling the precise API URL.

http://<hostname>/api/login will work, but http://<hostname>//api/login will not. Though some user agents ignore the double //, FusionAuth treats them as two different URLs, and returns HTML which the API client doesn't know how to parse (hence the error message).

Our billing is hourly, but we bill up-front rather than in arrears.

This means if you sign up we will charge you $75 USD (if you chose the basic hosting).

If you cancel before the end of your billing period, we issue you a refund for the unused amount, pro rated to the hour.

Yes. FusionAuth Cloud starts with Community Edition as the base version.

You can purchase one of our paid editions for both the self-hosted or FusionAuth Cloud. Once you enter the license id for a paid edition, it activates the premium features in FusionAuth (including Breached Password Detection, LDAP support, Advanced Registration Forms).

@dan You're fine, i just read something wrong

@dan Thank you for your support. Fixing the signature just saved me another couple of hours (also coming from https://fusionauth.io/blog/2020/07/14/django-and-oauth/) ^^

The JWT TTL can be configured per application, so if you were using a different application for OIDC vs an API - then you could do it.

But if you don't want to use multiple applications, then it is not possible, at least currently.

I could see a use case for asking for a JWT with a TTL equal to or less than the configuration and that request being honored, that could be a feature request. But as of right now, the only option is different applications.

You can put whatever you want in the theme pages, but it's a good idea to keep them lean so the user has a quick login experience. After all, most folks don't care about auth except when it doesn't work!

You can optionally pass info in the state parameter, that will come back to the caller. This can be encoded JSON, as long as it is url safe. You will want to make sure that you don't put too much stuff in there, as there are URL length limits for browsers (though I learned that chrome has a URL size limit of 2MB!). Here's an example of using the state parameter for application state.

Or if you have different applications and redirect URLs, then just gathering metrics on the URLs may give you insight into who is using login, and from where.

Sort of depends upon what type of analytics you need.

Hiya,

I think this is what you are looking for:

https://fusionauth.io/docs/v1/tech/apis/identity-providers/openid-connect/#complete-an-openid-connect-login

So you aren't so much starting the OIDC flow as finishing it. This would be if you were building your own login form.

Another alternative that I think does what you want is to provide an idp_hint parameter, which will direct the user right to the correct login form, without requiring an additional click: https://fusionauth.io/docs/v1/tech/identity-providers/#hints On a re-read of your question, I think that's what you're looking for.

If I misunderstand your question, please let me know.