indieweb / indieauth

IndieAuth.net website code and IndieAuth Specification
52 stars 7 forks source link

Should the use of explicit app schemes be discouraged as redirectUrls? #20

Open EdwardHinkle opened 6 years ago

EdwardHinkle commented 6 years ago

So with the launch of Indigenous I have noticed several issues with app schemes (example: Indigenous://callback/path).

First, I have found many new IndieAuth implementations due to time/complexity and potentially not understanding why it's important, have not implemented Client Information Discovery (4.2). WordPress IndieAuth just added a warning of the mis-match between the app scheme and the client_id, which seemed okay. However, there was some more insidious issue that is still not understood as a variety of people who had all sort of different authentication issues with Wordpress were all fixed when I changed my app scheme to be based off of my client_id with a 302 redirect url (One such example: https://github.com/indieweb/wordpress-indieauth/issues/70).

Another example of an IndieAuth issue is Micro.blog's implementation which currently, just stops processing if the redirectUrl is not underneath the client_id. Instead of the warning that WordPress provides, Micro.blog just rejects the authentication. In the next update (no timeline given), from what I understand, Micro.blog does plan to change over to the WordPress way of authenticating with a warning.

However, the seeming lack of awareness and numerous issues makes me wonder if one of two things needs to happen.

  1. We recommend using 302 redirects to app schemes from urls underneath the client_id All of my issues seems to be fixed by changing my redirectUrl from indigenous://callback/path to https://indigenous.abode.pub/ios/redirect-path. Where https://indigenous.abode.pub/ios/redirect-path is just a 302 redirect to indigenous://callback/path.

  2. We develop some sort of testing suite for app schemes so that people can test their IndieAuth implementations against app schemes to ensure it works correctly.

sknebel commented 6 years ago
  1. The spec should call this possibility out more clearly, and suggest a warning if verification isn't happening due to the implementation not verifying (instead of a verification failure). There's a lot of SHOULD's in those sections, and they could maybe be clearer.

Test suite and coverage of these cases in it certainly is a good idea, I'll try to think of good options for this.