Thank you for sharing the "protocol police" document Filip. You have made my day š
On Sat, 25 Oct 2025 at 14:05, Filip Skokan <[email protected]> wrote: > Slack also likes to return token_type=bot which they then playfully ask > developers to send to their API with a bearer scheme. > > I find these funny, collect them over time, and once there's loads of them > will issue a print of "attempts at oauth, the greatest hits". > > Nothing to fret about, it's not that oauth doesn't define what the > response must be, it does, it's that some implementers just don't find > conformance to a spec to be something to strive for. > > Of course the best course of action is to file issues at the service in > question (or the protocol police <https://www.rfc-editor.org/rfc/rfc8962>) and > wait for a fix. I'm not keeping track or those anymore. > > - Filip > > 25.āÆ10.āÆ2025 v 14:37, Warren Parad <[email protected]>: > > ļ»æ > > Kalivaradhan, > > The token response already has a "minimal universal response schema" > defined in the original spec: > https://datatracker.ietf.org/doc/html/rfc6749#section-5.1 > > The providers that don't match it, have explicitly decided to disregard > the spec. Of your list, the ones that are not spec compliant are > onlyĀāSlack, Reddit, and Apple. However Apple does return spec compliant > and it also provides Open ID compliant responses, including the id_token. > So in your list only Slack and Reddit violate it. And Reddit doesn't offer > OAuth, so that leaves us with Slack. > > And if we look at Slack, we actually see that they do support the OAuth2 > spec already: > https://docs.slack.dev/authentication/sign-in-with-slack/#response > > So I'm not sure what else there is to say, other than thatāI can't think > of a response other than I completely disagree with everything you are > saying. The spec already exists, and those providers who implement > OAuth2/Open ID are already following the spec. > > - Warren > > On Sat, Oct 25, 2025 at 2:01āÆPM Kalivaradhan Aadharsh <[email protected]> > wrote: > >> Hi everyone, >> >> Iām a developer building a multi-provider authentication system and Iāve >> run into a consistent pain point when integrating different OAuth 2.0 >> providers. >> >> While the OAuth 2.0 spec defines the overall flow, it leaves the token >> response structure fairly open. This has led to each provider returning the >> access token in different formats for example: >> >> - Slack: { "authed_user": { "access_token": "..." } } >> - Google, Discord: { "access_token": "..." } >> - Apple: { "id_token": "..." } (signed JWT) >> - Reddit: requires Basic Auth, different schema >> >> From a developerās perspective, this inconsistency makes it difficult to >> build generic OAuth integrations or SDKs that can handle multiple providers >> without writing provider-specific adapters. While technically all of these >> are ācompliant,ā it results in unnecessary complexity for implementers. >> >> Proposal: >> As OAuth 2.1 is being discussed, would it be possible to define a minimal >> universal response schema that all providers should adhere to at least >> ensuring that `access_token`, `refresh_token`, `token_type`, and >> `expires_in` are always top-level and consistently named? >> >> This would help developers build interoperable tooling and SDKs while >> still allowing providers flexibility for additional metadata. >> >> Iād love to know if this topic has been discussed before or if thereās an >> open draft related to improving response consistency. >> >> Thank you for your time and for maintaining such a critical protocol for >> the web! >> >> Best regards, >> Kalivaradhan Aadharsh >> Student Developer | Orion Auth Project >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
