Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppLink as Authorization Endpoint #853

Open
DavDag opened this issue Jun 30, 2022 · 4 comments
Open

AppLink as Authorization Endpoint #853

DavDag opened this issue Jun 30, 2022 · 4 comments
Labels

Comments

@DavDag
Copy link

DavDag commented Jun 30, 2022

Configuration

  • Version: 0.11.1
  • Integration: native with Kotlin
  • Identity provider: custom

Description

I'm trying to integrate the AppAuth authorization flow by replacing the default browser tab with a custom activity that handles login (& 2FA). The service configuration has two links:

AuthorizationServiceConfiguration(
    // authorization endpoint
    Uri.parse("https://oauth2.example.it/oauth/auth"),
    // token endpoint
    Uri.parse("https://oauth2.example.it/oauth/token"),
)

I've declared a working AppLink bound to the "authorization endpoint" inside the manifest but the authIntent created by the library contains a package specification that permits only to the selected app to open the intent.

The method that creates the intent is this, in particular, line 565:

intent.setPackage(mBrowser.packageName);

effectively disallowing AppLinks to work.

I'm not sure if the reason behind the implementation was relative to security or ease of use but the RFC 8252 has a section (7.2) which state:

[...] When the browser encounters a claimed URI, instead of the page being loaded in the browser, the native app is launched with the URI supplied as a launch parameter. [...]

Thus, it should not be against rules.

In the end, for now, I've found a dirty solution that changes the intent's content:

binding.button.setOnClickListener {
    val service = AuthorizationService(this, advancedConfiguration)
    val intent = service.getAuthorizationRequestIntent(authorizationRequest)
    //
    intent.extras?.apply {
        val i = getParcelable<Intent>(KEY_AUTH_INTENT) ?: return@apply
        i.setPackage(null)
        putParcelable(KEY_AUTH_INTENT, i)
    }
    //
    resultLauncher.launch(intent)
}

And I'm working at the LoginActivity to correctly integrate the flow (ex. by starting an intent to simulate the last redirect to the RedirectUriReceiverActivity).

Thanks in advice,
Davide.

@DavDag
Copy link
Author

DavDag commented Aug 31, 2022

Sorry to bother you. Any update on the question?

@agologan
Copy link
Collaborator

Think you're on the right track, though you may be interested in this proposed change #622
While I did find the proposal good, I never spend the time to properly review it and integrate it.
Your feedback on that PR would be appreciated, and if it works as expected maybe I can set aside some time and integrate it.

@DavDag
Copy link
Author

DavDag commented Sep 15, 2022

I'll take the time to evaluate and test the proposal as soon as possible.

@DavDag
Copy link
Author

DavDag commented Sep 16, 2022

Android contains an intent attribute named "autoVerify" that does exactly what the PR adds.

I do not know if reimplementing the mechanism is the right thing to do. If the PR's author (@fabian-hk) can help us, it would be appreciated.

I propose to integrate what the android developer site suggests.

from the link above:

Android App Links verification
When android:autoVerify="true" is present in at least one of your app's intent filters, installing your app on a device that runs Android 6.0 (API level 23) or higher causes the system to automatically verify the hosts associated with the URLs in your app's intent filters.

Please, anyone able to improve my consideration or correct it should speak!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants