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

Yes, if you enable TLS for the email configuration, mail.smtp.starttls.enable is set to true.

Here's more about the javamail config (which I expect you are already familiar with, just adding for completeness): https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html

solved. I needed to type DELETE.

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

Great, thanks! Please let us know how the additional troubleshooting goes. I'd look at the error messages and see if anything funny sticks out.

How can I configure FusionAuth do that automatically?

This is not possible through FusionAuth configuration. Feel free to file a feature request: https://github.com/fusionauth/fusionauth-issues/issues

You can update a user after they are created to specify an application authentication token. So you could register a webhook and listen for registration events and then update the user who just registered: https://fusionauth.io/docs/v1/tech/apis/registrations/#update-a-user-registration

And if it is not possible yet, is it possible to generate it in a programmatic way from the client-side (a Vue app just after user logged in) without exposing an API key?

Nope, you'll need some server side code or you'll need to expose an API key. You could limit the API key to only be able to update users, but you would need to make an API call to update the user and generate the auth token.

HTH.

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.

Hi Marco,

I'm unable to replicate using Google's login with google button (this is with 1.19.8).

Here's what my JWT looks like:

{ "aud": "ffbbef97-a2c0-49eb-990d-bd6e96acf2f9", "exp": 1603227230, "iat": 1603223630, "iss": "acme.com", "sub": "8c5a7890-3deb-4fc7-a5d9-29cf396847c5", "jti": "f091312c-47ce-4125-a9a0-a2d2e7279ce3", "authenticationType": "GOOGLE", "email": "<email address>", "email_verified": true, "applicationId": "ffbbef97-a2c0-49eb-990d-bd6e96acf2f9", "roles": [ "USER" ] }

I'm not quite understanding what is going on, because my JWT doesn't look like yours. Typically if a user is registered for an application you'll receive an aud claim with the application id in it (more here on that).

I also note that the JWT you provide shows you are logging in with the PASSWORD method, not google, facebook or apple.

Maybe it makes sense for you to lay out, step by step, the auth process a user goes through where they don't get the roles claim? Because I'm not sure what's going on.

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.

But if I put these in the application, won't this be a security problem?

If you put them in a javascript app, yes. But if they are in the php application only, then it'll be like a database password. Not really a security issue.

You could also inject them as an environment variable or pull from a secrets manager; however you manage your database credentials, I'd suggest doing the same with the client id/secret.

That's awesome, glad it got worked out.

Please share here when your app is released!

We could review this decision, perhaps it makes sense to leave this information in the API response.

In the event of a database breach, the attacker would have all of the necessary information, but in the API response we initially thought it better not to leak any information about how this user's password may be hashed and stored.

Awesome, glad to hear it! Thanks for letting me know.

@mgetka great point. I think we use requests-oauthlib in the user portal example app.

It's worth calling out that there are two levels of integration between FusionAuth and your application.

The first is with OAuth/OIDC. These are standards and FusionAuth should work with any library that supports those standards. (If not, please open a bug, as we want to know about that ). This will handle authentication and authorization. The data you can get about the user is limited, though you can put custom claims in your JWT with lambdas if what you need is in the user or the registration objects. If this meets your needs, definitely recommend using a library like the one mgetka or I suggest.

The second is with the FusionAuth API. This has access to all the APIs, including things that just aren't accessible via the standards. Stuff like registering a user to an application or adding/removing them from a group, or adding custom data to the user.data field.

I'm sure you know all that @mgetka , just wanted to document for others as it was confusing for me when I started integrating.

Hiya @tim-0

I'm not sure I understand your flows. It sounds like you want to handle two use cases.

Use case #1 User is not in FusionAuth system, but is in the OIDC system. You want them to authenticate via the OIDC provider. Then they should register with FusionAuth. Then, going forward, they should authenticate against FusionAuth. Or maybe against the OIDC system too? Not clear.

Use case #2 User is in the FusionAuth system. They should still be verified against the OIDC system somehow but then shown a different page, no registration needed? After that, they'll auth against FusionAuth? I'm confused here because I don't know why they'd need to be verified against the OIDC system here.

Maybe it's worth taking a step back and explaining what you are trying to accomplish. Which system is going to be the system of record for the users. The OIDC system or FusionAuth? Do you have multiple applications in FusionAuth and the OIDC system only is used for one of them?

If you could lay out in detail the flow of the different user paths, I might be able to understand things a bit better.

Thanks!