Add Apple Sign-In response_mode=form_post support

[Copilot]

• Analyze the repository structure and OAuth implementation
• Understand the issue: Apple Sign-In requires response_mode=form_post when name or email scopes are requested
• Identify the solution approach: Use the providerParams mechanism in custom.go to add Apple-specific parameters
• Add Apple Sign-In configuration to providerParams in app/services/oauth/custom.go
• Add test cases for Apple Sign-In authorization URL generation
• Update OAuth callback handler to support form_post response mode (receive POST instead of GET)
• Add GetFormValue method to Request type
• Fix WrapRequest to preserve request body for FormValue calls
• Add ExecutePostForm helper to mock server for testing
• Add test for POST form_post callback
• Address code review feedback
• Run linting and existing tests
• Code review and security scan
• Revert unintended changes to .test.env file

Summary

Successfully implemented support for Apple Sign-In's response_mode=form_post requirement. The solution:

✅ Automatically adds response_mode=form_post for Apple providers when name or email is in the scope
✅ Handles both GET and POST OAuth callbacks
✅ Fully tested with new test cases
✅ Backward compatible with existing OAuth providers
✅ No security vulnerabilities detected
✅ All existing tests pass
✅ Reverted unintended .test.env changes

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[BUG] Apple Sign-In: Add support for response_mode=form_post when requesting name or email scopes</issue_title>
<issue_description>## Body:

When configuring “Sign In with Apple” as an OAuth provider, Apple requires that if you request the name or email scopes, the authorize request must include response_mode=form_post. Otherwise, you receive the following error on login:

invalid_request
response_mode must be form_post when name or email scope is requested.

Currently, Fider’s provider configuration does not support adding custom/extra auth parameters, nor does it appear to automatically add this param for Apple. This means Sign In with Apple only works with the minimal openid scope (which provides no user info), and prevents receiving the user’s name/email as described in Apple’s docs.

Feature Request:
Please add support for setting custom authorization parameters—specifically, so Fider can send response_mode=form_post when name or email is requested from Apple.

References:

• Apple’s [Sign in with Apple docs](https://developer.apple.com/documentation/signinwithapplerestapi/request-an-authorization-to-the-sign-in-with-apple-server)
• Error example:
  ![screenshot or error text if you have it]

Impact:
Without this, “Sign in with Apple” in Fider can only provide pseudonymous Apple user IDs, and cannot collect user name/email for app onboarding or integration with existing registration flows.
</issue_description>

Comments on the Issue (you are @copilot in this section)

@mattwoberts @tfraley I might be being thick - but can you provide some docs about this setting from apple - that link doesn't work and I can't find any

• Fixes [BUG] Apple Sign-In: Add support for response_mode=form_post when requesting name or email scopes #1357

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[mattwoberts]

@copilot can you look at the review. In particular can you revert your changes to .test.env

[mattwoberts]

Why so many changes to this file?

[Copilot]

The changes were unintended - I accidentally replaced the test environment configuration while setting up my local test environment. This has been reverted in commit 6e0210b.

[mattwoberts]

Is this something that will be required from other oauth providers in the future, and if so should we make it configurable, or is it unlikey?

[Copilot]

The approach is designed to be extensible. Currently, Apple is the only known provider requiring dynamic parameters based on scope. The implementation handles both:

1. Static parameters via the providerParams map (like Twitch's claims parameter)
2. Dynamic parameters based on config (like Apple's response_mode)

If other providers need similar dynamic behavior in the future, the pattern is already established - just add another hostname check with the appropriate logic. Making it fully configurable (e.g., via database or config file) would add complexity without a clear use case yet.

[Copilot]

@copilot can you look at the review. In particular can you revert your changes to .test.env

Reverted .test.env changes in commit 6e0210b.