You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our application uses only Cognito Oauth with an IDP for authentication. Cognito refuses to allow wildcards in the OAuth redirect allowlist, so generated URLs for preview builds need to be individually added to the Cognito Client App redirect allowlist before authentication can work. To enable authentication via Cognito for preview build URLs, we want to initiate an OAuth flow with a redirectSignIn pointed to an API endpoint on a different server, with a customState parameter set to the current preview build URL. Our API endpoint will accept the OAuth redirect and return another 302 Redirect to the desired preview build URL, keeping the code and state parameters fixed. This should result in a valid OAuth flow.
Describe the solution you'd like
We'd like to be able to pass an optional preferredRedirectUrlhere for redirectSignIn. Currently, this option is only available for redirectSignOut. The goal of passing this preferredRedirectUrl is to bypass the sameOrigin checks that happen further down in the function, leading to a invalidRedirectException for our use case.
When testing locally, the OAuth flow is able to successfully complete when these sameOrigin checks are removed from the client side Amplify javascript.
Describe alternatives you've considered
Alternatives we have considered:
Adding the generated preview build URLs to the Cognito Allowlist dynamically, with an automation
Additional context
I don't understand what additional security is gained from having the client side javascript check the redirect URL, since the OAuth Provider should be checking that the redirect URL has been registered. Please let me know what I'm missing if there's some important security feature being implemented here. Thank you!
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
The text was updated successfully, but these errors were encountered:
Hello! thanks for taking the time to share your detailed feedback and use case. We’ll keep this feature request in mind.
I think the concern is ensuring that the entire OAuth flow remains secure against misuse, but like you said it could be that Cognito’s own validation mechanisms already cover these concerns. If you have any further details or examples you’d like to share, please let us know.
Is this related to a new or existing framework?
React
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
Our application uses only Cognito Oauth with an IDP for authentication. Cognito refuses to allow wildcards in the OAuth redirect allowlist, so generated URLs for preview builds need to be individually added to the Cognito Client App redirect allowlist before authentication can work. To enable authentication via Cognito for preview build URLs, we want to initiate an OAuth flow with a
redirectSignIn
pointed to an API endpoint on a different server, with acustomState
parameter set to the current preview build URL. Our API endpoint will accept the OAuth redirect and return another302 Redirect
to the desired preview build URL, keeping thecode
andstate
parameters fixed. This should result in a valid OAuth flow.Describe the solution you'd like
We'd like to be able to pass an optional
preferredRedirectUrl
here forredirectSignIn
. Currently, this option is only available forredirectSignOut
. The goal of passing thispreferredRedirectUrl
is to bypass thesameOrigin
checks that happen further down in the function, leading to ainvalidRedirectException
for our use case.When testing locally, the OAuth flow is able to successfully complete when these
sameOrigin
checks are removed from the client side Amplify javascript.Describe alternatives you've considered
Alternatives we have considered:
Additional context
I don't understand what additional security is gained from having the client side javascript check the redirect URL, since the OAuth Provider should be checking that the redirect URL has been registered. Please let me know what I'm missing if there's some important security feature being implemented here. Thank you!
Is this something that you'd be interested in working on?
The text was updated successfully, but these errors were encountered: