Add Buffer as a new web provider integration

[dgates82]

Summary

Adds Buffer as a new web provider integration for #1801.

Buffer's userinfo endpoint is GraphQL-based (like Linear, Meetup, and SubscribeStar), so it needed the same three-part handling: overriding the HTTP method to POST, forcing a JSON request body instead of the default form encoding, and assembling the GraphQL query from the configured field list. The response comes back wrapped in the standard GraphQL "data" envelope under "account", and Buffer's account identifier field is "id" rather than the standard "sub", so both are remapped the same way existing providers with similar quirks already are.

Buffer also returns an "iss" authorization response parameter without advertising authorization_response_iss_parameter_supported, since it has no discovery document. Handled the same way as the existing Google case.

PKCE (S256) and client_secret_post are both required by Buffer for every client type, confidential or public.

Validation

Verified with a full live authorization code + PKCE flow through the sandbox AspNetCore client, using a real Buffer OAuth app registration:

options.UseWebProviders()
       .AddBuffer(options =>
       {
           options.SetClientId("<client_id>")
                  .SetClientSecret("<client_secret>")
                  .SetRedirectUri("callback/login/buffer");
       });

Confirmed the full pipeline end to end, including the GraphQL-specific userinfo handling, and the resulting claims (email, subject identifier) came back correctly.

[kevinchalet]

Thanks for your PR, @dgates82! 👍🏻

[dgates82]

Thanks for the quick and detailed review @kevinchalet. I'll apply the fixes and get it back to you shortly!

[dgates82]

@kevinchalet I think that covers everything. Let me know if I missed anything or if you'd like to see any other changes

Thanks!

[kevinchalet]

@dgates82 looks great, thanks!

Could you please share a screenshot of the claims table displayed by the console after a successful authorization flow? Feel free to blur the sensitive values.

N.B: last time I checked (i.e a while ago 🤣), Buffer didn't allow new client registrations. Has anything changed in this regard?

[dgates82]

of course @kevinchalet

Let me know if you need anything else.

They did have a migration from a "legacy" rest api to an graphql api, and there was some vagueness in the documentation whether I would be able to get an OAUTH2 client for the new api, but I was without any issues.

[kevinchalet]

Let me know if you need anything else.

Any chance you could try the console app? It gives a much more interesting view of the claims returned by a provider 😃

They did have a migration from a "legacy" rest api to an graphql api, and there was some vagueness in the documentation whether I would be able to get an OAUTH2 client for the new api, but I was without any issues.

Very interesting. Glad to see they've changed their mind: not being able to create a registration was definitely an annoying blocker to port that provider 🤣

[dgates82]

Hm. When I add the same registration to console app I get a "could not connect to Buffer."

I'll try to dig into this tomorrow.

[kevinchalet]

Interesting. What redirect_uri did you configure?

[dgates82]

In the console (same as in the AspNetCore i have .SetRedirectUri("callback/login/buffer");

In Buffer's api config I have https://localhost:44381/callback/login/buffer for the callback.

[kevinchalet]

In Buffer's api config I have https://localhost:44381/callback/login/buffer for the callback.

Ah yeah, it's likely the port: the console app uses 49152, 49153 and 49154 (the first port available is chosen). Worth trying to change it in Buffer's config to see if it helps.

[dgates82]

Ah, it looks like the redirect_url's are only using http? Is that a config I'm missing?
oi_reduri: http://localhost:49152/callback/login/buffer

Buffer only accepts https redirect urls.

[kevinchalet]

Ah, it looks like the redirect_url's are only using http? Is that a config I'm missing?

Yeah, the console app only supports HTTP redirect_uris (because well, no CA will ever give you a valid TLS server certificate for localhost anyway 🤣).

Scratch that. Let's merge this PR 😃

[kevinchalet]

Merged! Thank you very much for your PR and congrats for your first contribution to OpenIddict! ❤️

[dgates82]

Thanks, glad to help!

I took a quick look at Digital Ocean as well, and if you want I should have some time to try to add it next week too. It looks like it does require a credit card to sign up for an api key, but as long as they're not hiding anything in the fine-print the free tier should cover everything we need to validate it.

[kevinchalet]

I took a quick look at Digital Ocean as well, and if you want I should have some time to try to add it next week too. It looks like it does require a credit card to sign up for an api key, but as long as they're not hiding anything in the fine-print the free tier should cover everything we need to validate it.

Great idea! Let me know if you need help with that provider 👍🏻