| 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) and wait for a fix. I'm not keeping track or those anymore. - Filip Kalivaradhan,
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 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]
|
