OAuth2 group:join scope

Feature Requests Website Features
#1

As a app developer on Roblox and a service owner who uses Roblox’a OAuth 2.0 it is currently not possible for us to make users join the app’s group after successful OAuth 2.0 authentication.

The solution for for this would be addition of a group:join scope, here is couple examples of usage of this scope:

Usage examples:

1. Bot/Alt protection.

May groups have problem with alt accounts and bots joining in and spamming ads or inappropriate things on the group wall, solution to this would be usage of OAuth 2.0 with the group:join scope. How?
The group may build a third party authentication barrier which would require user to authenticate with OAuth 2.0 before being able to join the group (additionally alongside created_at claim) and make the user automatically join the group after succesfull auth. This would allow groups to keep bots and spammers out of the group.

2. Service users group

Some sites/services may want users to join their company/community groups after authenticating into their service, usage of a group:join scope would be perfect for this since after succesfull authentication the user would join the group.

Why would it be needed:

1: Enhanced Security Measures

The introduction of the group:join scope is crucial for safeguarding closed and private communities or app-exclusive groups from bot infiltration and unwanted activity. Without this feature, groups risk being flooded with spam and scams, particularly on their group walls, compromising the community’s integrity and trust.

2: Streamlined User Integration

The group:join scope streamlines user integration processes within Roblox communities, enabling seamless onboarding and fostering a sense of belonging. By automating group membership upon OAuth 2.0 authentication, developers and service owners can efficiently connect users with relevant groups, enhancing engagement and participation. This simplification not only reduces friction in user journeys but also cultivates stronger community bonds, driving sustained interaction and satisfaction.

Possible insecurities and risks

1: Group swapping and forcing

This scope could potentially force join every authorized user into group after e.g. the group got locked or to farm group members for e.g. group selling.

2: Lack of User Consent Control

The group:join scope may raise concerns regarding user consent and control. Without proper implementation measures, users might find themselves unexpectedly added to groups without explicit consent, potentially leading to privacy issues and discomfort. This lack of transparency can erode trust between users and service providers, undermining the integrity of the OAuth 2.0 authentication process.

Summary:

The addition of the group:join scope would be a perfect solution for app developers, services and other entities who utilize Roblox’s OAuth 2.0 system.

3 Likes
#2

I see this as too much of a security risk then actual useful feature. If you wanted a person to join your group or be required to join the group.

1 Like
#3

I disagree as you have to be 13+ and confirm twice to authorize the app which would reduce such misuses. Also the authorization screen shows you have permissions the app is using.

As you can see:

image
image1322×696 55.7 KB

#4

I feel as if this could be used for a process similar to malicous Discord servers in-where they use a bot with a similar scope to this for ‘verification purposes’. In-reality they are just using the scope to instantly pull members from their old server (when it gets inevitably deleted) to their new server.

2 Likes
#5

The user has to authorize the OAuth 2.0 application, so still it’s user’s responsibility on whether they are or not authorizing.

Also such integrations would be probably removed as soon as such big pull would occur so it doesnt make sense.

#6

I appreciate the potential value in having this, but at the same time, I feel there are numerous security flaws that haven’t been accounted for by this proposal.

First of all, if an application wants to force a user to join a group, which group the user is being made to join needs to made clear at authorisation time, or otherwise, they could be made to join hundreds of groups without their consent. Individual consent must be given to join particular groups, and it needs to be done in such a way that the consent given is explicit - perhaps users must explicitly tick a checkbox to join the requested group.

Additionally, this would bypass the captcha that Roblox sometimes puts before allowing users to join groups to prevent abuse, so there’ll most certainly be bad actors abusing such a system to mass join groups to advertise scam links in group walls. This isn’t to say that such captchas aren’t already bypassed, but at the same time, we shouldn’t be making it easier for these bots.

It’s not to say that there is not great value in having this ability; in fact, I think that it opens up some exciting new possibilities for future systems, but that there needs to be more considered thought about the implications of opening this capability up and potential mitigations.

#7

You can always remove the authorization for the app, also by using OAuth 2.0 user is directly responsible for permissions they give the app.

#8

Neither use case #1 nor #2 will work with your feature request as written.

A group:join scope would allow you to send a group join request on behalf of a user. The group itself still would need to be open for join requests. OAuth2.0 doesn’t give the app any additional permissions the user wouldn’t have themselves – it’s just a filter on the user’s permissions.

It looks like you don’t need a group:join scope at all. You just need a way for an API key to accept join requests. Then, you would have users log in somewhere with the openid scope and do some check on your application to ward off spammers, and then your application uses the API key to accept the user’s group join request. The user can/would still send the join request themselves in this model and then go through your app to get it accepted. (perhaps this could be streamlined if there was a group:join scope so that you could prompt the join request for the user and then immediately accept it with the API key afterwards)

I recommend retitling your topic to be about your problem rather than proposing a specific solution since it may not be an appropriate one for your problem (as above). You need more than a group:join scope to achieve what you want to achieve.

1 Like
#9

group:join scope would make user automatically join the protected group after authorization, that’s all what is needed.

It would as I said main goal of group:join scope would be making authorized user join the protected or app user only groups.

I do know, but at the same time it would be better for the app itself to handle it not API where you can officially only read:

image
image1535×182 13.4 KB

#10

Open Cloud improves around security, the reason that it takes so long to develop features is that they are working behind the scenes to improve security and develop API that won’t be like the old Roblox API. Roblox Staff spoke about this on devforum (cant find the link to it) that the Roblox API is very very risky and deprecated, OpenCloud is the replacement of that.

#11

Thats why we should have official either API for group accepting and role changing or OAuth 2.0 group:join scope.

#12

The last time I heard, that is in development by the OpenCloud Team and the group accepting has been in private beta.

Regarding your second point, and as multiple said earlier, the scope group:join scope is too risky and could and would have a security risk attached to it.

This is a very very good statement regarding why it is.

#13

You should reffer to my response about it too:

Also the group:join scope is indeed only thing that is needed in order for private or app only groups to be protected e.g. in combination with “created_at” class where you can block accounts younger than some date.

#14

This is a bad example, and does not explain the security flaws of it.

#15

What security flaws? The scope would literally only makde the authorized user join the group, where the user can remove the authorization and leave the groups at any time.

#16

This would be your answer to your question.

#17

You’re missing the point. What you’re asking for isn’t compliant with OAuth2.0. This scope would not be a filter on top of existing permissions of the user.

What you’re asking for cannot be solved with just an OAuth2.0 scope. It would break the mental model of OAuth2.0 and not be secure.

I recommend re-reading my post again and additionally reading up on OAuth2.0 to better understand why this makes no sense. This would mean “let the user give a permission to an app that they do not have themselves (forcing a group to accept their join request)”.

Again, recommend rewriting your thread to be problem-focused and not solution-focused.

1 Like