Support for Custom Query Parameters in signInWithRedirect /authorize URL

[sarossilli]

Is this related to a new or existing framework?

No response

Is this related to a new or existing API?

Authentication

Is this related to another service?

Cognito

Describe the feature you'd like to request

I would like the ability to define custom query parameters when Amplify calls the /authorize URL for the signInWithRedirect function. Currently, some external OpenID Connect (OIDC) authentication providers require additional query parameters to be included in the /authorize request but Amplify does not appear to support this.

Context & Use Case:

Some OIDC authentication providers, like Auth0 and Twitch, require the inclusion of custom query parameters in the /authorize request for advanced functionality. For example, these parameters can request specific claims or modify the login experience.

According to the Auth0 documentation, custom query parameters can be used to provide additional context to the Universal Login experience.
Similarly, the Twitch OAuth documentation specifies the need for the claims query parameter in the /authorize request to include non-default claims.

Problem:

Currently, Amplify’s signInWithRedirect implementation does not allow users to define or append custom query parameters to the /authorization URL. This lack of flexibility restricts integrations with certain OIDC providers that require specific query parameters to function correctly.

Here’s a reference to the current implementation of signInWithRedirect that lacks support for custom query parameters:
signInWithRedirect implementation.

Describe the solution you'd like

Proposed Solution:

Add an optional extraQueryParams Property to SignInWithRedirectInput and append each parameter defined to the /authorization url.

Solution Description:

I propose adding an extraQueryParams property to the AuthSignInWithRedirectInput interface (which is aliased as SignInWithRedirectInput). This property will allow developers to pass custom query parameters that can be appended to the /authorize request when using the signInWithRedirect method.

The extraQueryParams property will be an optional Record<string, string> object, allowing for flexibility in defining key-value pairs to be appended to the /authorization URL.

Key Implementation Points:

1. Modify the AuthSignInWithRedirectInput Interface:
   Add the following property to the interface:

extraQueryParams?: Record<string, string>;

Since SignInWithRedirectInput is an alias for AuthSignInWithRedirectInput, this change will automatically apply to both.

2. Update the signInWithRedirect Function:

Ensure that the function processes extraQueryParams and appends them as query parameters when calling the OIDC provider's /authorize endpoint. These parameters should seamlessly integrate into the request URL.

3. Example Usage:

Auth.signInWithRedirect({
  provider: 'Auth0',
  extraQueryParams: {
    screen_hint: 'signup',
    claims: '{"id_token":{"email":null,"preferred_username":null}}'
  }
});

In this example, the custom screen_hint and claims parameters will be appended to the /authorize URL as part of the request for additional control over the authorization process.

Why This is the Best Solution:

It leverages the existing AuthSignInWithRedirectInput structure.
It provides flexibility and extensibility for different OIDC providers that require additional query parameters.
It avoids the need for hacks or workarounds, such as hardcoding query parameters or modifying the endpoints parameter in the `defineAuth method.

---

Why call the property extraQueryParams?

This was chosen to align with oidc-client-js implementation - where they have defined this property as extraQueryParams

Describe alternatives you've considered

Adding the Exact claims Query Parameter Directly:

I could hardcode my specific claims query parameter directly into the authorization request, but this approach is not extensible. It would limit the ability to include other potential custom parameters in the future or for other providers. This would create a rigid solution, lacking the flexibility to accommodate varying authentication flows with different providers.

Modifying the endpoints Parameter in defineAuth:

Another alternative would be to directly modify the endpoints parameter in the defineAuth method, as seen in the Amplify documentation. However, this isn't a viable solution for two reasons:

CDK and Cognito Restrictions: Both the AWS CDK and Cognito explicitly check and reject URLs that contain query parameters in the endpoint definitions. This creates a constraint that prevents me from injecting the necessary parameters through this method.

Hacky and Inappropriate Approach: Even if it were technically feasible, directly modifying the endpoint URL to include custom query parameters feels like a hack rather than a proper solution. It introduces unnecessary complexity, and maintaining such a workaround could lead to further complications in the future.

---

For these reasons, adding an extraQueryParams property directly to the signInWithRedirect function is the most appropriate, flexible, and maintainable solution.

Additional context

I will start working on this - but wanted to create an issue to discuss the feature in case of any concerns with this addition.

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

[cwomack]

Hello, @sarossilli 👋 and thank you for creating this feature request. I'll review this with our team internally and get back if there's any further questions or context that we're looking for.

There are also some related feature requests on the repo tied to improvements to signInWithRedirect API (or the older Auth.federatedSignIn() from v5) captured in issues #13343 and #10226 respectively. Just noting these so that any feature work done with signInWithRedirect() considers a few of these asks from our community!

[bajcmartinez]

+1