@pradhanv88 Would something like the OpenID Connect identity provider work for you?
@elliotdickison Thanks for posting!
I shared this internally.
Regarding your first point, I agree a table would of MAU/$ would be helpful.
Regarding your second point, really appreciate that (and the feature suggestions/bug reports you make!). We discuss features and pricing pretty regularly, and I'll surface this comment next time we do so.
@brad, you may need to check if the lambda is actually running. I did this by creating a JWT Populate lambda and setting debug enabled = "true" and logging some info.
Then I logged in. I could see the results in the token.
More importantly, I was able to go to `System -> Event Log' and see that it ran.
Can you confirm yours is running? You should also be able to log the values you think you are setting for confirmation.
We've been running FusionAuth on Fly for a couple years now. Great experience all around.
And here's more detail docs from @Alex-Patterson : https://fusionauth.io/blog/fusionauth-on-fly-io
Hmmm. Do you have any documentation from NextCloud for generic OIDC providers? FusionAuth usually works with generic documentation, so that might be a good place to start looking.
You can also enable debug on the FusionAuth application you are configuring and look in the event log to see if there is more information that might help you debug this issue.
@ghstahl I think we had a similar conversation on Slack 
For future readers, if you want to be able to distinguish how a user logs in (which idp they use), this might be helpful:
If I were you, I'd look at two things:
- the user login success event: https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success which has the identityProviderId It is provided as an event, so I don't know if it'll work for you, but it will tell you on every login event which idp was used. You could possibly store that off someplace and build a system to exchange an id token for the idp used. I'd have to think more about how that works, but it might be possible.
- setting up in your own app a 'sign me in' button and not using an idp hint. You'd instead build the authorization URL for each idp and build a link for entry into each navigation area. https://fusionauth.io/docs/apis/identity-providers/openid-connect#complete-an-openid-connect-login You'd let the user login and then come back. The redirect URL could be different and that would be the distinguishing feature.
If a user started at /googlestart, clicked the 'sign me in' button, and arrived back at /googleendpage and had a valid token, the user went through the google process.
If a user started at /secretidp1start, clicked the 'sign me in' button and ended up back at the /secretidp1endpage with a valid token, then the user went through the secret idp 1 process.
@asenjowork Awesome, I'm glad you figured it out!
Thanks for the tips! I do love that customizing FusionAuth's theme templates allows you to accomplish pretty much anything. For our use-case - lots of custom forms for lots of tenants - I would prefer to be able to use the advanced registration form feature instead of polluting theme files with JS snippets. At that point I think I might as well hardcode the HTML for the fields instead of adding JS.