Proxy servers can store cached copies of sites. You will get the data from the proxy when you access a particular location.

Use the managed domains feature. From the docs:

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.

Documentation:

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/

Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

Thanks!
Josh

@eirikur That is awesome, thanks so much for sharing your settings.

That is an encoded (signed) JWT being sent in response to the user info request that the FusionAuth OIDC identity provider is making.

This is technically allowed in the OIDC spec, but we do not currently support this response type.

Per spec, the endpoint should support a JSON response which is the default unless the client requests a signed or encrypted response body.

I would look at how your client is registered and see if it is asking for a JWT userinfo response at that time, and change it to be a normal JSON response. You could also file an issue detailing your needs for FusionAuth to support this user info response type.

If that isn't an option, you could also look at using a SAML Identity Provider if the remote identity source supports that.

While FusionAuth supports both well, if you have the option to use SAMl v2 or OIDC, I would always recommend OIDC.

In general, it is much much simpler to use, debug, configure, etc.

It sounds like you're asking if you can modify the issuer claim.

You can control the "Issuer", or iss claim, in two different ways:

You can set it in the tenant config, where it will apply for all JWTs issued for that tenant. You'd modify that by navigating to "Tenants", then your tenant, then "General". Modify the "Issuer" field value to be login.example.com. You can set it at the individual JWT level by modifying the JWT populate lambda. You would do this if you wanted to have a different issuer based on some information from the user or registration data. (This does not appear to be the case here, just including this for completeness.)

I'm not clear if you have more than one tenant in your system; if you do, you can either change the "Issuer" setting for the default tenant (which is what is provided when no tenantId is on the URL) or request the endpoint with a tenantId appended, like this:

https://login.example.com/.well-known/openid-configuration?tenantId=<tenantid>

That should work ok. The only reason not to do it this way - is because you’re sort of emulating the OAuth frontend’s usage of this API which in theory is subject to change.

Re: state, additional key value pairs will be stored, however if our front end is consuming the URL, you won’t have access to the API response which will contain that state information.

We have users that have been successful in configuring with AD v2. We have not yet tested or updated the documentation.

This may be helpful. https://github.com/FusionAuth/fusionauth-issues/issues/855

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.

These are generated in the UI. So the values are not available from the API.

However you can derive them yourself as well. We just take the URL + /oauth2/authorize?... + redirect_uri etc.

Yea, that flexibility would be ideal IMO, although the registeredLogoutURLs should be workable for us at this point. FWIW that is actually the behavior I assumed before digging into the docs. I'll definitely add the issue to GitHub, as I think it's probably part of the path to getting OIDC Certification which appears to already have an issue.

Thanks!

@dan
I faced similar kind of issue last time, I am still searching for some proper solution.