@dan yes this answers my question perfectly! I appreciate the detailed answer.

Thanks! I appreciate it.

I will keep track using the link, and i'll thumbs up the issues.

Thanks! I appreciate it.

I will keep track using the link, and i'll thumbs up the issues.

Hey Dan,

If that is considering idp initiated SSO when fusion auth is acting as the SP then yup!

Yup! that is the exact use case we are looking to accomplish.

When attempting to initiate SSO via an idp (in this case OneLogin). I am getting the following error.

Logging in through an SP initiated flow works perfectly fine.

{
  "error" : "invalid_request",
  "error_description" : "The request is missing a required parameter: redirect_uri",
  "error_reason" : "missing_redirect_uri"
}

this is the ACS url: http://localhost:9011/samlv2/acs should i be adding redirect uri to that url to get an idp initiated flow to work?

When using FusionAuth's front end to authenticate users. Is it possible to have a remember my email button?

Here is the use case :
When a user attempts to login using Fusion Auth, we want to support remembering a user's email. This is so when a user that is attempting to login via SAML identity Provider (using managed domains) for the second time, we can automatically redirect them to their identity provider.

Is there a way to achieve this currently with FusionAuth's front end?

@dan yes this answers my question perfectly! I appreciate the detailed answer.

Great suggestion about using the JWT!

I am indeed using oauth for authentication. Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?

with the former just saving me the effort of getting the user profile in my api?

Thanks for the speedy response!

Is there a workflow within fusion auth, to not authenticate a self registered user until their registration is verified by email?

My current workaround is to locally track which users have been verified in our own database. Then using webhooks listen for the user.registration.verify event to update our own DB and allow access.

Did I miss anywhere in the FusionAuth docs that would enable this workflow to avoid the mentioned workaround?