Use "app link" for redirect

[ghost]

App-claimed "https" scheme redirect URIs have some advantages
compared to other native app redirect options in that the identity of
the destination app is guaranteed to the authorization server by the
operating system. For this reason, native apps SHOULD use them over
the other options where possible.

https://tools.ietf.org/html/rfc8252#section-7.2

It seems this is something we have to do, but how is this enforced? is this something that needs "domain validation" in the play store? Or how does that work?

[ghost]

https://developer.android.com/training/app-links/index.html

[ghost]

Seems only supported Android >= 6. I think currently we require Android >= 5 for the app. Is it okay to update the requirements to Android >= 6? Android < 6 is no longer supported in any way by Google.

[ghost]

I did manage to get it to work at some point, but now it is broken again. No idea what is going on, it won't return to the correct place in the app, i.e. it will go back to the "add provider" page and not to the main screen.

It is strange that you need to override the manifest with a "scheme" but you can't specify app links directly with this method with AppAuth so you DO have to modify the manifest of the app itself as well, so it seems there are now two ways to specify it. Ugly!

[ghost]

What is your idea about this? Is this feasible?

[dzolnai]

Seems only supported Android >= 6. I think currently we require Android >= 5 for the app. Is it okay to update the requirements to Android >= 6? Android < 6 is no longer supported in any way by Google.

I think users would prefer compatibility with older devices with having the drawback of a less secure redirect. If we use custom tabs, then the redirect goes back to the app immediately, so this is only the case with the default browser AFAIK.

I did manage to get it to work at some point, but now it is broken again. No idea what is going on, it won't return to the correct place in the app, i.e. it will go back to the "add provider" page and not to the main screen.

That should be easily fixable, we can detect if the app is opened from a URI scheme, and then open the correct screen.

It is strange that you need to override the manifest with a "scheme" but you can't specify app links directly with this method with AppAuth so you DO have to modify the manifest of the app itself as well, so it seems there are now two ways to specify it. Ugly!

I'm not entirely sure I understand what you mean, but with adding the scheme under an activity in the Manifest, you tell the system that the specific activity can be opened via that URL scheme you just added.
If multiple apps specify the same scheme, then the system provides a chooser.
App links is an extension to this system, where you upload a special file to a specific URL, by this you make a statement to the system that you are the owner of the website, and the given app belongs to you, so the system should not even ask which app to open.

[ghost]

I think users would prefer compatibility with older devices with having the drawback of a less secure redirect. If we use custom tabs, then the redirect goes back to the app immediately, so this is only the case with the default browser AFAIK.

For security software it makes sense to only support the versions of Android that are still supported and receive security updates... Not sure what is the lowest version that still receives (monthly) updates? Does e.g. the Fairphone actually fix security issues after Google stops supporting an Android version? Not sure what makes sense here...

App links is an extension to this system, where you upload a special file to a specific URL, by this you make a statement to the system that you are the owner of the website, and the given app belongs to you, so the system should not even ask which app to open.

It would be nice to implement this (using the HTTPS URL) because then we can disable the "authorize" dialog for the Android app! If this is not a (big) problem. then I guess it makes sense to go for it! :)

[dzolnai]

Not sure what is the lowest version that still receives (monthly) updates?

This is manufacturer-dependent, but it is usually 2 years after release of the device.
I would say, maybe 8.0 is getting some updates still.

Does e.g. the Fairphone actually fix security issues after Google stops supporting an Android version?

Probably not.

It would be nice to implement this (using the HTTPS URL) because then we can disable the "authorize" dialog for the Android app! If this is not a (big) problem. then I guess it makes sense to go for it! :)

The problem with this is, it only works with https redirect URIs. Right now our URI is org.eduvpn.app:/api/callback. I see there was a similar problem for iOS so maybe it is time for Android to switch too?

[ghost]

https://github.com/eduvpn/vpn-user-portal/blob/v2/src/OAuthClientInfo.php#L42

'https://android.app.eduvpn.org/api/callback',  // Android >= 6

Could this work?

[dzolnai]

Looks good to me!
The json file needs to placed to https://android.app.eduvpn.org/.well-known/assetlinks.json in this case.

[ghost]

If you can provide the contents of what needs to be in there exactly I can put it there :)

[ghost]

(Oh, and there's also one for the Let's Connect! build...)

[dzolnai]

Will do on Monday!

[dzolnai]

@fkooman for this file I need the certificate fingerprint of the release keystore (see this documentation for how to retrieve it).
Can you put the SHA256 hash in this ticket?
If Let's connect is signed with a different keystore, then the hash of that one too.

[ghost]

Let's Connect!

[fkooman@fralen-tuxed-net META-INF]$ keytool -list -v -keystore ~/LC.jks 
Enter keystore password:  
Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: lc
Creation date: Jun 28, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Let's Connect! for Android
Issuer: CN=Let's Connect! for Android
Serial number: 15b7eec4
Valid from: Thu Jun 28 13:27:08 CEST 2018 until: Mon Nov 13 12:27:08 CET 2045
Certificate fingerprints:
	 MD5:  FC:72:C9:A9:37:7C:12:3E:A7:A0:DD:4F:19:D1:99:7E
	 SHA1: D2:28:F9:36:73:DD:34:CF:C5:FC:BD:35:0D:96:CD:26:86:FE:90:1A
	 SHA256: 7D:8C:0E:CC:A9:E0:B2:3C:64:27:EE:D1:EA:A3:D8:ED:DB:5E:3F:9C:5E:EF:AB:5E:36:C1:4D:B5:6C:78:F8:5A
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions: 

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E3 ED 9D 83 B1 18 D9 6C   E1 18 EE 86 B9 16 8F C6  .......l........
0010: 2E F4 00 FF                                        ....
]
]



*******************************************
*******************************************



Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /home/fkooman/LC.jks -destkeystore /home/fkooman/LC.jks -deststoretype pkcs12".

We are still searching for the eduVPN keystore ;-)

[dzolnai]

According to this line, it should be android.jks in your home dir :)

[ghost]

I also verified that this certificate/key was used to sign the last version available on https://app.letsconnect-vpn.org/ :)

[ghost]

According to this line, it should be android.jks in your home dir :)

That's in a build-VM, not on my local machine, so I don't have it anymore there. Rogier for sure has it!

[mkoelewijn]

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: eduvpn
Creation date: 1 Feb 2017
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=SURFnet eduVPN, OU=eduVPN, O=SURFnet, L=Utrecht, ST=Utrecht, C=NL
Issuer: CN=SURFnet eduVPN, OU=eduVPN, O=SURFnet, L=Utrecht, ST=Utrecht, C=NL
Serial number: 308a7a
Valid from: Wed Feb 01 11:52:59 CET 2017 until: Sun Jun 19 12:52:59 CEST 2044
Certificate fingerprints:
SHA1: FB:18:4E:61:9E:C2:8F:2C:6A:6C:C7:9D:C8:30:73:77:74:14:63:DF
SHA256: 04:B7:64:91:88:22:93:EA:4C:08:2D:F7:B6:06:A0:88:EF:69:27:B6:3C:70:F0:56:0F:7A:CA:85:B0:23:02:D6
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 01 90 B7 FA 5B 7E 79 4F 3C D8 37 17 DF 8B 93 F9 ....[.yO<.7.....
0010: 71 0B 6E A0 q.n.
]
]

[dzolnai]

Thanks!
@fkooman we cannot use the same redirect URI for Let's Connect and EduVPN. Do you also have a similar redirect URL for Let's Connect?

[ghost]

https://github.com/eduvpn/vpn-user-portal/blob/v2/src/OAuthClientInfo.php#L55

                'https://android.app.letsconnect-vpn.org/api/callback',  // Android >= 6

[dzolnai]

@fkooman attached you can find the two asset links files.
Can you make eduvpn_asset_link.json available on the following URL: https://android.app.eduvpn.org/.well-known/assetlinks.json
And lets_connect_asset_link.json on this URL: https://android.app.letsconnect-vpn.org/.well-known/assetlinks.json

Here's the documentation, if you would need it.

asset_links.zip

[ghost]

the one for eduvpn.org should be online now!

[ghost]

letsconnect-vpn.org is almost finished, just waiting for DNS.

[ghost]

Let's Connect! link is also fixed now!

[dzolnai]

App links are now available. I am not able to test if it really works because I don't have access to the release keystores, could you please test both Let's Connect and EduVPN @fkooman?

Reproduction steps:

1. Turn off Custom Tabs in Settings
2. Log into one of your institutions. At the last step, when you authorize the app, you should jump back into the eduVPN / Let's Connect app just as you would with Custom Tabs.

If you see the following selector, then app links is NOT working, or the app is not signed with the correct keys:

[ghost]

From which build/commit/branch should this work?

[dzolnai]

It was merged with #190, master should work.

[ghost]

1. Install Fennec (Firefox build from F-droid)
2. Set it as the default browser
3. enable or disable "custom tabs", doesn't matter
4. OAuth redirect URL is not recognized, eduVPN app is not (re)opened, error in browser about missing document.

[ghost]

It seems only to work with Chrome as default browser and with Custom Tabs on.

(Galaxy A6 with official Samsung rom, Android 9).

Build 84

[dzolnai]

It seems that this will not be useful for our users, if it only works on Chrome (I tried it too with Fennec and Firefox, and they both don't work).
I assume our only option is to go back to the old redirect URI, and forget about app links.
What do you think?

[dzolnai]

As discussed, I have reverted the app links change. App links seems not to be ready for production, at least not for redirect URLs.

[ghost]

The documentation seems to have improved a lot:

https://developer.android.com/training/app-links/verify-site-associations

[babandiaye]

Hello try to use my URL application website but i have javax.net.ssl.SSHHandshakeException java.security.cert.certpathValidatorException Trust hanchor for certication path not found. When i use my own certificat (or Let'sencrypt ) it's failed but with iPhone it's ok website also it's ok Please how to fix it.