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]
