App Not Handling Deep Link Redirects in Silk Browser

Hello everyone,

I am currently developing an OAuth2 authentication feature, but I’m having trouble getting the app to capture the redirected URL.

Goal

I want the app to automatically open when a specific URL is accessed via a redirect.

manifest.toml

schema-version = 1

[package]
title = "MyApp"
version = "0.1.0"
id = "jp.sample.test"

[components]
[[components.interactive]]
id = "jp.sample.test.main"
runtime-module = "/com.amazon.kepler.keplerscript.runtime.loader_2@IKeplerScript_2_0"
launch-type = "singleton"
categories = ["com.amazon.category.main"]

[[message]]
uri = "https://example.com/oauth2redirect/"
sender-privileges = ["*"]
receiver-privileges = ["self"]

[offers]

[[offers.message-target]]
uris = [
  "https://example.com/oauth2redirect/"
]
uses-component = "jp.sample.test.main"

[[offers.module]]
id = "/jp.sample.test@IDeeplinks"
includes-messages = [
  "https://example.com/oauth2redirect/"
]

[[offers.interaction]]
id = "jp.sample.test.main"
launch-uris = ["https://example.com/oauth2redirect/"]

I am using Linking.openURL() to initiate the authentication request.

Debugging Results

When I log into the device shell and check the access permissions, the output is as follows:

Bash

sh(com.amazon.dev.shell):/$ vmsgr check-access --package jp.sample.test "https://example.com/oauth2redirect/?code=test_123"

Checking access for package: jp.sample.test

Dependencies for: https://example.com/oauth2redirect/?code=test_123

Canonical Uri: https://example.com/oauth2redirect/

Required Module: /jp.sample.test@IDeeplinks [PASS]

Required Sender Privilege(s): * 
    Sender Privilege Check:  [PASS]
    Message Target Check (Not applicable to broadcast or unicast):  [PASS]
    Required Receiver Privilege(s): self 

    Receiver Privilege Check:  [PASS]

If I manually trigger the link using vmsgr send "``https://example.com/oauth2redirect/?code=test_123``", the app opens correctly.

The Problem

However, the app fails to open when triggered via the Silk browser in the following scenario:

  1. Navigate to a URL in the Silk browser that is unrelated to the Deep Link settings.

  2. From that page, the browser is redirected to the Deep Link URL (https://example.com/oauth2redirect/``...).

I suspected that the automatic redirect might be getting blocked, so I tried providing an explicit link to https://example.com/oauth2redirect/ on the page and clicking it manually, but the result was the same—the app did not open.

What is the correct way to ensure that redirected URLs (or manual links within the browser) are handled by the app?

Hello @gen

Thank you for the detailed report. Your manifest configuration is correct - the vmsgr check-access passes all checks and vmsgr send successfully opens the app, which confirms the Vega messaging layer is properly set up.

The issue is that the Silk browser is not routing https:// URLs to the Vega messaging system - neither via redirect nor manual click. We are investigating whether this is expected behavior or a gap in the Silk browser’s integration.

  • Immediate workaround - handle OAuth inside a WebView:
    Instead of launching the Silk browser for OAuth, use @amazon-devices/webview
    within your app and intercept the redirect URL directly:
<WebView                                                                      
    source={{ uri: oauthLoginUrl }}                                             
    onNavigationStateChange={(navState) => {                                    
      if (navState.url.startsWith('https://example.com/oauth2redirect/')) {     
        const code = new URL(navState.url).searchParams.get('code');            
        handleAuthCode(code);                                                   
      }                                                                         
    }}                                                                          
  />

This keeps the entire OAuth flow within your app and avoids the browser-to-app handoff entirely. Your existing https:// redirect URI works as-is - no need to change your OAuth provider configuration.

We are checking the Silk browser deep link behavior internally and will update you once we have more clarity on this.

Reference documentation:

Warm Regards,
Ivy