Sanity check on usage of serverless functions and Auth0

Help
,
1

This is something I’ve longer wondered about and when I’ve tried to investigate it in the past, it never really made sense to me. I don’t know why, but today things clicked and… well it was almost too easy, hence me looking to ensure I’m not doing anything stupid.

I’ve got a simple web page making use of the getting started experience - ie a login/logout button and profile display.

In that code, I then grab the user’s sub value. I take this, and pass it to a serverless function that uses the management API to get the user, and the ‘real’ access token for their login, in this case, Google.

On my settings side, I’m asking for Contacts permission, which meant I needed to supply a real client id and secret in my settings, but once I did that, I was able to login with the additional scopes, and my serverless function could get the access token, and then call Google’s Contacts API, and get data.

This all worked perfectly, but, is it safe? Is there anything else my serverless function should do outside of just taking in the sub value and using it with the management API?

3

Hi @raymondcamden,

I can’t make any guarantees about security here or do a security review, per se.

With that said, this generally makes sense.

A few things to consider:

  • If you are passing around data to publicly available endpoints, you will want to protect those endpoints (usually with an access token, in this context).
  • You never want to expose a client secret to the client side like a SPA/native app, so these requests (to the management API) should all be coming from a secure backend, your serverless function.

Hope this helps!

4

Thank you. To the second point, yep, the intent is a serverless function. To the first point, my assumption is that if I require a sub value from the user logging in, then my serverless function is ok to be ‘public’ since you wouldn’t be able to use it outside of that. I mean, I could login to my app, see my sub passed to the endpoint, copy that, and use that, but from what I saw in testing it can’t be used forever.

5

Hm, I’m having a hard time visualizing the setup with the serverless function.

6

Front end is just basic Auth0 code from the walkthrough - ie a login/logout button. I added a bit of code to get sub, then I pass that to X, X being my serverless function, where X uses the management API to get the profile for the user plus their Google token to then use to get info from a Google endpoint (in my case, Contacts). I keep saying X cuz technically, I’m using a Node.js script where I copied in the sub value.

7

Thanks. To confirm, you have a client side application (like a SPA with React/Vue/Angular) that needs to make a request to a backend API (your node serverless function). For this, you would typically want to add an access token to the request for authorization.

8

So I know I can run auth0Client.getTokenSilently(); and it gets a token. Is there an Auth0 management API my serverside code could use to validate the token

9

Yep, I would suggest this package: GitHub - auth0/node-jsonwebtoken: JsonWebToken implementation for node.js http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html

Here’s an example:

var jwt = require('jsonwebtoken');
var jwksClient = require('jwks-rsa');
var client = jwksClient({
  jwksUri: 'https://{YOUR_DOMAIN}/.well-known/jwks.json'
});
function getKey(header, callback){
  client.getSigningKey(header.kid, function(err, key) {
    var signingKey = key.publicKey || key.rsaPublicKey;
    callback(null, signingKey);
  });
}

jwt.verify(token, getKey, options, function(err, decoded) {
  console.log(decoded.foo) // bar
});
10

Also, some serverless function support JWT verification natively. For example:

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.