2FA information for organization members

schema-request

#1

It doesn’t look like we can currently retrieve 2FA status of organization members, as mentioned here, a capability that does exist in the current REST API. This is critical information that organization owners will need in order to properly monitor the security health of their org(s). I would expect to see that status when querying the members of the organization.

Is there a plan to surface this information in the GraphQL API? Thanks!


#2

Hi @juliaferraioli!

I think we would love to surface this information via the GraphQL API somehow!

Digging into how it’s exposed in the REST API, it looks like the current method that we use to expose that information is a a filter to display users where it’s not enabled, and not as an attribute on the user. Do you have any strong preferences about one method or the other? It seems as though the use case you’re talking about might lend itself to the filter, but I’d love to understand more.

Thanks!


#3

That’s a really good question, @nickvanw! I’m a current consumer of the information via the REST API. While the filter is great for checking on overall health, it’s hard if we’re trying to dig in one user who is part of a large organization with many members (although hopefully not many of them have 2FA disabled!).

I think at this point I only have a slight preference to the attribute, especially since (if I understand correctly) there’s not a way to query a specific member of an organization with GraphQL. If we’ll get that capability at some point, then it might be better to have it as an attribute so that querying the member also returns their 2FA status (having to query the full list to check on one or two members seems wasteful).

I’m still pretty new to GraphQL though, so feel free to let me know if I’m misunderstanding anything here.

Thoughts? Might be good to get other consumers of this filter from the REST API to weight in on how they’d like to see it implemented.


#4

This is great, thanks for the reply!

While I haven’t ever had to personally use our REST API to manage a large set of users in an organization, I can imagine that there are good use cases for both of the things we’re looking at - filtering, as well as digging into a single user.

From my perspective, I think the place to start on the GraphQL API would be to add a filtering method to allow you to perform a pass over everyone - this would prevent you from having to loop through every user in the organization to check for who’s got 2FA on.

Once we’ve done that, I could see us adding the information into a special UserEdge for the Organization -> Member connection - this would allow us to leverage GraphQL to put this information at the edge for a good way to represent this.

I’m going to open an internal issue for all of this, and we’ll update this thread if anything changes! Thanks again for the request, and for talking it through with me!


#5

That would be awesome! I didn’t want to ask for both, but I’m glad we’re in alignment there. I appreciate it. Happy to talk through our use case any more with y’all as you go along with fleshing out the administrative functionalities; I imagine we are one of the heaviest users of the organization administrative side of the API.


#6

Was there any progress on this @nickvanw? Thanks! :slightly_smiling_face:


#7

@bswinnerton is there a way to know whether a feature request is making progress in the internal tracker? Maybe a badge here on the discussion? (e.g. “planned”?) I guess I should just be patient but I’m also wondering whether the request has been internally abandoned, in which case I should look for alternative way to get the information eventually. Thanks :slight_smile: