A bit confused on why there is two claims for a users display name.
Also, will we get access to the email scope like most OAuth providers supply?
A bit confused on why there is two claims for a users display name.
Also, will we get access to the email scope like most OAuth providers supply?
Youâre right, you canât abuse those permissions.
When I say âbad actorâ I donât just mean abusing the permissions granted to the app, but also e.g. exposing the user to inappropriate content, or exposing their device to malware if the app is a desktop/mobile app, etc. There are many aspects of bad abuse that we want to avoid, not just permission abuse.
This is for compatibility with the OpenID Connect standard spec:
https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
Currently the answer is no, we do have a scope for it for our own internal apps but it is not exposed because of a perceived security/privacy risk. Weâll need to do more investigation here and discussions internally on if/how we could do this in a safe way.
That being said, want to be clear that weâre not currently planning to do that, as the team has other priorities related to OAuth2.0 scopes at the moment that would be more broadly useful to the community.
So I was reading the docs to familiarize myself on the OAuth 2.0 and I came across this on the token section of the docs. I think (may be wrong but it looks like it is wrong unless it means something else wrong) that it should say âbecause it checksâ not as it currently says âbecause ot checksâ. I could not tell if âotâ means something or possibly it just suppose to say âitâ so I thought I would send a message here.
Is this uniqueness case sensitive. For example, If i named my app ILoveRoblox
, could someone else name their app ILOVEROBLOX
.
Sorry itâs a typo. A fix has been submitted and should be reflected soon.
There are several rules we apply here, but yes, case-insensitivity is one of them.
Only one of those two apps can exist.
Is the ability to create OAuth applications limited only to the group owner at this time? I am attempting to create one under a group with this account, but the group is held by a holding account, and despite granting all permissions I am not able to create an application.
Weâll keep an eye on all the approved apps. If any of them becomes malicious for some reason, weâll suspend the app and investigate. If it turns out the users are not at fault by uploading the bad assets, we of course wonât publish them. More detailed policies will be shared in the future.
Yup that is correct. It is really annoying cuz the team I am working with on a site want to use this linked to our group which has a holder account so us three devs can all do group owner perms but this is not possible at the current moment.
Correct. I donât expect this to be very high friction at the moment because app configuration should be a rare action (as there isnât too much there that would need to be tweaked on an on-going basis).
Weâre aware that itâs more ideal to eventually implement a proper group permission to allow collaborators (or on a per-app basis).
Sorry for the late response. I had to look back at a ton of use-cases over the years, compile them into something digestible and then, type it all out. I didnât want to just give you random info since, that probably wouldnât help you, your team or associated people out. Iâm sure that I am missing a few but, these were the most common things that people use and have been begging for OAuth support on for years now.
For users.roblox.com, the functionality provided as of today is ok but, doesnât serve a real use-case imo. Most of the users using my library (or others), typically use account info as means of verifying an external account with an account on Roblox. Many use the userâs description or (rarely) joining a game. I think if a âdescriptionâ property was added to the endpointâs response body, it would / should cover most cases that people would need.
For groups.roblox.com, the following endpoints are what people typically ask me about or use:
User headshots are also a big one that users ask about. Outside of those, I think most should be covered. The group urls are typically used for group administration and game administration on third-party platforms (discord, etc) and thereâs a lot of complaints about it not being supported yet through this. I was not able to find the exact url but, group-ranking automation tools are probably the most asked thing that I see and personally, get requested. I think having those URLs (GET, POST) would cover a ton of use-cases.
Thanks for the responses. And for following up on my other ones.
I understand these âold-schoolâ use case of adding a code or such to a description or playing a game to verify that you are in ownership of an account, but this should all be superseded entirely by OpenID Connect (this offering) as of today.
I can see it maybe being valuable to list a userâs blurb on a third-party app, but would love to see an actual product need for this from any third-party app developer before adding it. All of the verification use cases in regard to this seem obsolete at this point as they should just use OAuth2.0 workflow with openid scope.
Yeah aware of this one, this is a planned feature, thanks for bringing it up. We have some microservice stuff to sort out internally before we can provide it in the response.
Thanks for all the use cases for group API.
I seem to be Fixed this issue my self but i encounter some major bugs do i report them to the standard @Bug-Support or somewhere else?
If they are strictly oauth-related you are okay to post these here, or you can use the bug reporting process for it.
If they are not oauth-related yes please use the bug reporting process.
Are there any plans for more APIs to be accessible using OAuth? Specifically in regards to experience analytics, it would be extremely useful to be able to use the API to access the analytics from the creator dashboard.
Hey folks I checked with the team and can confirm we have people working on group / group role management scopes for Open Cloud and all of your use cases for group API are covered properly in the spec. Weâre going to roll this out iteratively (likely starting with read-only APIs and scopes) but the goal is to eventually have all group management supported via Open Cloud. We understand the priority of this.
On this comment specifically, this seems unnecessary once there is Open Cloud support for group management. Instead of using a separate account you would have the owner of the group authorize your app to use the APIs.
thank you for providing me with this information. I have decided to go with a well-documented bug report through the @Bug-Support team and I am looking to get this OAuth 2.0 bug fixed soon. Is there anyone specific who I should add to the bug report?
I have written a tutorial on implementing the most secure OAuth flow possible, aptly named, wellâŚ
This was originally a reply, but because of itâs comical length I have split it into a separate post as to not pollute this one.