[Feature] Add request/fetch/AJAX support to lambdas

[voidmain]

Add the ability to make HTTP requests from lambdas

Problem

Currently, lambdas are not able to make HTTP calls to external services. This makes it difficult to pull in additional data for users or to call APIs during different workflows.

Solution

Implement one of the standard JavaScript APIs for lambdas to make HTTP requests.

Alternatives/workarounds

None currently.

Related Issues

• Add phone number as loginId for push login and registration #208
• Oauth2 - AzureAD - Get User Picture #222
• Access to more data from a Lambda? #229
• Replace Nashorn JS Engine used for Lambdas #571
• Update Java version to next LTS (targeting 17) #1227

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[jerryhopper]

Suggestion:
Instead of requesting data from within the lambda function, how about passing a variable to the lambda via the auth-request?

Wouldnt it be handy if one could have some url-parameter in the authorization request, and have that accessible via the jwt_populate function?
This way, the authorization request could send data like the 'device-id' or alike - and have that reflected in the token after succesfull login.

the 'state' parameter could be used to stay within the openid standard, but a custom url var could suffice too.

[fdlk]

@jerryhopper The thing is, the code in the relying party is not always under control. The nice thing about the lambda’s is that in such cases they glue any discrepancies together.

[robotdan]

I'll note that the main limitation here is that we are using an old JS engine, and we will have to upgrade this soon as it being removed from the JDK.

So when we deliver issue #571 and replace Nashorn with something more modern, such as v8we hope to get this support for free more/less.

This is getting close to being on the short list due to the impending deprecation and removal of Nashorn from the JDK. We are currently on version 14, and it will be removed in 15 - and we plan to upgrade to 16 once available. So this deadline is approaching quickly.

AdoptOpenJDK shows version 16 availability in March of 2021. https://adoptopenjdk.net/support.html

[mooreds]

Could possibly be a premium feature.

[robotdan]

We could consider that - it may be tricky to enforce this unless we parse the lambda or can turn off the feature within whatever engine we end up using.

[mooreds]

It looks like there are some permissions levels you can set in graaljs: https://www.graalvm.org/reference-manual/embed-languages/#access-restrictions

Not sure which of them applies to network access.

Could also provide a custom node fetch library: https://github.com/node-fetch/node-fetch (maybe) or expose fetch via a java object which performs a check before making the call?

[trevorr]

I'd like to lobby against making this a paid feature. Unlike the other paid features (e.g. breached password detection, LDAP/legacy integration, advanced MFA, customizable forms) which are primarily of interest to established companies and/or are add-ons not likely to influence the architecture of customer applications, this has use cases that are pretty fundamental for building a new app, such as fetching app-specific data (e.g. permissions) to be included in each JWT.

To put it another way, I'd like to be able to build my app the best way I know how with free/community FusionAuth. Once it's generating revenue, I'd be happy to upgrade to support FA and get all the nice add-ons, but I wouldn't want to start reworking my authorization model at that point.

[mooreds]

@trevorr thanks for the feedback. We spend a fair bit of time internally discussing what makes sense as a paid feature and what makes sense to put in the community edition and always appreciate feedback from the community.

[trevorr]

Thanks @mooreds. I definitely appreciate you having some of that discussion here and giving us the opportunity for feedback.

[robotdan]

To add to what @mooreds said - this is not necessarily going to be paid feature, but anything is possible. This was opened a while back when we just knew that we wanted to support this in some fashion - and we didn't know if we'd have to build this ourselves or get it for free within the script engine.

We are going to have to ditch Nashorn very shortly for something better since it is now deprecated in Java 15. See #571

My guess is that whatever option we pick to replace Nashorn will come with AJAX support and we won't have to write it ourselves. In this context, I don't know that it would make sense to lock any of this down.

[trevorr]

Do you have any thoughts on how this affects lambda types to support asynchronous code? That seems to be the other piece of this. For example:

function populate(jwt, user, registration) {
  fetch(...).then(() => {
    // How do I let FusionAuth know I'm done populating?
  });
}

If using a modern JS engine, I suppose you could return a promise to let FA know it needs to wait. That should be compatible with existing lambdas (which don't return promises).

[robotdan]

Good question @trevorr - no idea. ;-) That is future @robotdan 's problem. TBD.

[lilyannh]

This is a show stopper for the app I am currently working on (I need to be able to augment my JWT with session level data during login). I actually find #267 (comment) about simply passing in the value as a variable, to address my needs just fine. It's also the simplest solution, given that you wouldn't need to worry about async).

They way I see it, my application can do the lifting for the AJAX immediately before sending the login api call, so I don't need FusionAuth to be able to do it from within the lambda.

[franklouwers]

What's the latest on this? This is preventing us from rolling out FusionAuth

[mooreds]

@franklouwers we're been discussing this internally, the update to java17 (included in release 1.32) makes it more straightforward to implement. But in general we can't commit to timelines outside of a signed professional services statement of work. I'm sure you understand that we have multiple competing priorities (haha, doesn't everyone!), but we'd love to get this out because it looks really useful.

Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap/

[mooreds]

Internal note: https://inversoft.slack.com/archives/C026DDDPQRY/p1640110581003100?thread_ts=1640110546.002900&cid=C026DDDPQRY has a useful example of possible lambda code.

[robotdan]

PSA:

Support for HTTP requests will be out in 1.35.0.

With this support you'll be able to make a REST call to FusionAuth over localhost, so in theory that should open a lot of doors for getting more data in the lambda. If you can get it with a FusionAuth API, you can get it in the lambda.

The first release is just a tech preview, we'll be adding more features shortly such as secret management.

[theogravity]

Is there documentation / examples on how this works?

Edit:

I found it via

https://fusionauth.io/docs/v1/tech/lambdas/#using-lambda-http-connect