Filtering/limiting user data

Moonshine

Kicking the tires w/ FusionAuth and really love things so far. Very well done

There's just one thing I haven't been able to figure out:

Is there any way that user information (phone number, email, potentially custom data, etc) can be selectively filtered/limited so that an application doesn't have access to "everything" about the user ?

I realize that's a rather broad question, and may take some followup, but I'll give a couple examples:

Going the OAuth2 route, if a user authenticates for an application, the JWT can be used to call /api/user and get (as far as I can see) very complete user data (including any custom user data, all registration data, custom registration data for other registrations, etc) regardless of whether they are even technically registered to the application they just authenticated with.

Going the OpenId Connect route, it seems the /oauth2/userinfo endpoint returns all claims about the user that would fall under the OIDC scopes of email, address, profile, phone, and openid, as the only scope options in FustionAuth seem to be offline_access and openid?

Anyway, I'm definitely not an auth expert, and would gladly take a scolding and RTFM if I'm overlooking something or misunderstanding some concept. Really just looking for any insight.

Thanks!

-James

dan

No scolding available on this forum .

When you authenticate a user, you can customize the generated JWT using the JWT populate lambda. So applications which receive the JWT from your client can get whatever information the lambda puts in there, and you can also remove items (except for the three reserved claims). Just realize that whatever you put in your JWT is going to be readable by clients as well. See this for more info.

If you don't want to populate your lambda, you could build your own secured api (which could be secured in any way you'd like) which would request information from the user FusionAuth api and filter the JSON to remove unwanted attributes.

Going the OAuth2 route, if a user authenticates for an application, the JWT can be used to call /api/user ...

I don't see that functionality here. Can you point me to where it says you can provide a JWT to an API to retrieve user information? The link I referenced indicated you provide an API key, which is an entirely different way of authenticating (not tied to a user or session).

dan

Whoops, I did find the "Retrieve a User using a JWT" section here: https://fusionauth.io/docs/v1/tech/apis/users#retrieve-a-user which doesn't require an authenticated fusion auth client. My apologies.

If you're concerned about a rogue client getting a JWT and then calling this API, I'd lock down access to FusionAuth (via a proxy or at the network level) and then build a proxy which does filtering of the user attributes returned to keep any sensitive data out of the client's view.

Moonshine

Thanks for the replies!

I guess the main thing I'm still struggling with is the use of OAuth "scopes" with FusionAuth. While our primary use for FA would definitely be authenticating our own applications using roles+groups for authorization (and where access to full user and registration info is "ok"), we would also need to use FA to delegate limited application access and user info to 3rd party applications.

For these 3rd party systems I was thinking the best route would be via OAuth2/OIDC, returning an access token limited to some scopes the remote application has access to, and an id token with limited OIDC user info claims. From my (admittedly limited) use of OAuth2 services implemented by others (GitHub, Auth0, etc) this is controlled by the scopes supplied (and agreed to) during the authorization request.

For example, OIDC has several scopes defined for requesting user info claims (profile, email, address, phone) during authorization. GitHub has many scopes defined for specific API acccess, like "repo:status" to allow API access to commit status messages.

But from what I can tell, scopes aren't really used by FA outside of:

"openid" - which adds the id_token and user info claims from all of OIDC's scopes (profile, email, address and phone).
"offline_access" - which adds a refresh token

The JWT lambdas definitely seemed promising, and I'm actually using them to extend the access token with some information, but AFAIKT they do not have any information about the scope(s) authorized to work with.

So at some level I still feel like I'm either overlooking something key, or perhaps our use case is just a little outside FA's focus. At this point we're still just kicking the tires, but I'd love to figure out a solution, as FA feels more comfortable and organized than alternatives in literally every other way -- which means a lot.

Moonshine

Seems I may have found part of the answer on this GitHub issue.

Looks like the issue went from Backlog, to Designing, back to Designing last month. Hopefully that's a sign there is hope.

dan

Hiya,

You're right, this is a use case on the roadmap (see #218 and #275), but scopes aren't implemented right now.

You can, of course, create different applications and different lambdas (which you can associate with your application via the API if it'd be easier). So you could have an application called email address only and have a lambda associated with that application which strips out all the claims except email address. The user should be registered with that application<-- this is important. Then the third party system could use OIDC against fusionauth and have the user authorize themselves against the email address only application. The id token lamba could then null out everything else in the id token except email and the required claims. It's not as simple as scopes, but should work for what you want to accomplish.

Another alternative is listed in one of those issues. People are using hydra in front of FusionAuth to layer on custom scopes. I haven't done this myself, but from nosing around their docs, seems like you'd just configure additional OIDC scopes and do the filtering there.

dan

@Moonshine Yes, issues move around based on engineering timelines and customer and user feedback. Here's guidance regarding our roadmap:

https://fusionauth.io/community/forum/topic/172/the-fusionauth-roadmap

If you'd be interested in professional services (building this out for you on a defined schedule), we'd definitely be happy to chat .

Moonshine

Thanks for all the info...

The multiple application route does sound doable with some FA API work (which we'll have anyway) and backend API work on our end. We are looking at an application per customer already, which this would then multiply by the number of 3rd party services we take on, but that's probably not an issue (at this point at least).

We're a pretty small team (4 developers) that's vastly outnumbered by salespeople. We'll definitely keep the pro services in mind, but I think there is enough for us to get started with. I have a feeling we'll be moving to the Developer service pretty quickly after launch though. As the LDAP integration and Reactor service is very appealing.

Honestly, thanks for your thoughts and time on this..

-James

dan

Hi James,

Glad to help! Let us know if you have any more questions.