While I think the documentation for this is poorly structured – I’ve never had to scroll through three different pages to find the URLs necessary for OAuth federation; only to find the .well-known URL implemented in the last one (I’m pretty sure with some errors btw); I am nevertheless very happy to see this feature rolling out.
We’ve already implemented it, and our team is already using it to sync account info, roles and permissions with our pre-existing systems!
The scopes cannot be changed without the user’s approval.
If an app wants extra permissions from its users, it will need to ask those older users (that authorized with old scope list) to re-authorize with the new scopes list.
You can check which scopes any access token / refresh token has by using the /v1/token/introspect endpoint.
Not sure I follow – feel free to just use the discovery document. (It’s linked directly in the side bar of the documentation) We’re running an OAuth2.0-compliant flow here but the documentation is aimed at people with all sorts of experience. Not just people who are already familiar with the OAuth2.0 protocol.
Feel free to submit suggestions and bug reports via #bug-reports:documentation-issues.
What are the “errors”?
I’m fully on board with this idea, but I believe the documentation is currently confusing for users following boilerplate OAuth instructions. I’ve been a beginner with OAuth and one of the most helpful things when reading documentation is when you can find the basic setup settings aggregated in a single page.
Here was my flow when setting this up, as a reasonably experienced user:
I also think these URLs should be displayed within Roblox’s OAuth configuration page, seeing as a significant portion of users would probably need them at the exact moment they are generating OAuth credentials.
The document returned specifies email as a scope under scopes_supported, which causes the app to error when requested, and which there is no documentation for.
I understand that it may be available for Roblox’s own internal apps, but if that’s the case I’d expect for Roblox to take advantage of the fact that the OpenID specification specifically allows for scopes to be omitted from the discovery document; or at the very least, for it to be documented.
There has to be a better way of going about this instead of blocking out features to many people like myself who aren’t bad actors but also aren’t going to send their official ID to Roblox. I have never been banned or had any serious moderation at all and yet I’m not trusted since I am not sending an ID in… I do not see how sending an ID makes someone less likely to abuse systems like this vs people like me who’ve had literal years of a clean record.
Aside from that, this seems like a good feature and could be very useful to developers like me as well.
if an asset is uploaded via oauth2 consent, who is liable? the application developer, the authorizing user, both, or no one?
like it would be terrible to authorize an app and then the app spam uploads tos breaking content to your account, but then at the same time it would be terrible if your app allowed integrations into other services and the app got banned because of one simple bad actor misusing your app.
I have a question. Does roblox support the “state” parameter for the initial authorization request? If not, will roblox be adding support for it?
Can a scope for group roles be possibly introduced? It would make the creation of ranking bots so much easier.
LETS GO!!!
This has just opened a massive door of possibilities just yearning to be released. This excites me just as much if not more than when HttpService released OVER 5 YEARS AGO! Proper authentication of a user is exceptionally important, and this functionality has just released a massive barrier on the ways we’ve been doing this.
@dragonknightflies What happens if a legitimate app is compromised & it does malicious things with its auth’d users?
E.g. if there’s an “asset manager” oauth app that gets comp’d, and it starts uploading inappropriate images for all of its registered users… how will Roblox handle situations like that? Obviously terminating the affected users is not an acceptable solution. Are there contingencies for these sorts of situations?
ICYMI:
The other documentation and the app management page clearly denote which scopes you can select from.
I agree, if you’ve been on the platform for years you are unlikely to be a bad actor.
In the general case though, this is a very strong measure we can apply to ensure high accountability on bad actors. It definitely helps deter abuse.
I’ll forward the feedback, but unfortunately I can’t promise a solution soon as we would need to define what a “trusted user” would look like outside of ID verification. (it’s very difficult to get a formula that covers everyone that it should apply to and isn’t easy to game or abuse)
This is a general risk when delegating permissions to apps. The same risk applies when you currently delegate your credentials to popular Roblox browser extensions (the risk is actually even worse here).
If you don’t think you can take this risk and/or the app is not highly trusted, I recommend not giving said app permissions to do things on your account.
To answer your question, abusive apps will be punished, but you are delegating permissions to that app, so I cannot guarantee that you would not be punished for the app’s behavior. On our end we cannot determine if you yourself uploaded something inappropriately through an app, or if the app did that for you, as the app is third-party software.
Yes, see the documentation. State parameter is supported and funneled all the way through in accordance with RFC-6749.
Can we hope to see eventually support for making an account handle users promotions and demotions, or even make it easier to run a business and have an account auto-join groups? It’s tedious to join every group by hand when you have a lot of customers looking for group management services.
Actually, this is exactly what OAuth2 was designed to prevent. It allows you to control other services can do. You can revoke access from those services at any time, remove permissions, etc. You allow the other services access to only specific things that that service needs, and you can see and control what things you’re allowing.
In this case, you can’t give an application permission to take items to begin with, but, even if that were an option, you’d have to intentionally give that website access to your items, which would be a bit silly if you don’t trust the service.
OAuth2 is used by Google, Microsoft, Discord, GitHub, and pretty much anything else that allows you to “sign in with XYZ” or allows you to give/revoke permissions to apps outside that service, without ever actually logging them in to your account in full.
The way OAuth2 works is that you tell Roblox (or Google, or Microsoft, etc, whatever you’re giving access for) what permissions to give the other service, and then Roblox will only let that service do exactly what you told Roblox to let them do. Once you’ve done that, Roblox will create an OAuth2 “token” to give to the other website, and then the website can use that token to ask Roblox to do certain things, or get certain information. Roblox will not do anything you didn’t allow for that token, and that token is tied to that service.
So is this feature available to all Roblox users or a certain group/requirement-met section of users
It’s available to everyone who has been ID verified
Great update, BUT.
I understand this is very new to Roblox and whatnot but having the App Review & Publishing every time you make a change seems unnecessary for an app that only uses the openid and profile scopes, for the other more damaging scopes I can understand.
I also made the mistake of publishing an update to a very busy website that allows users to link their Roblox account with the website and hit the cap in the first 10 minutes of the announcement. Hopefully, my app is reviewed fast lol
Also can we please have the ability to see how many users have connected to the app and maybe an endpoint we can set up for users who want to easily opt out of the service for example,
I have a setup if a user unlinks their Roblox account from the website, would be nice to send a request to Roblox letting you guys know this user has opt-out would make this a little more streamlined for the end user so they don’t have to go to the settings page and click remove ( just an added option ).
Here it is in action:
Finally I was waiting for this update to make some sort of a verification system with my discord bot.
But this… Another update that they put begin ID verification? 
I get it, “bad actors”, even though myself and many others, won’t fall into that category. They could’ve for example make a requirement: veteran + 2fa (auth key) requirement, or devforum verified or something, even this ID verification won’t 100% keep away the bad actors, they may be a bit more “trusted” as they verified themselves but not guaranted that the person won’t abuse the system and such.
