4 ms·

There was a great link someone commented on the post itself, describing how to implement a "login via email link" on mobile. https://auth0.com/blog/2015/12/04/h

by dkopi 10y ago

There was a great link someone commented on the post itself, describing how to implement a "login via email link" on mobile. https://auth0.com/blog/2015/12/04/how-to-implement-slack-like-login-on-ios-with-auth0/ https://auth0.com/blog/2015/12/04/how-to-implement-slack-lik... I haven't spent much time reading it, but I guess it works with deep-linking - the mechanism used when you click on a link to Facebook.com and it takes you to the Facebook app instead of the Facebook webpage. https://developer.apple.com/library/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html https://developer.apple.com/library/ios/documentation/Genera...

stephenr 10y ago
That only works for first-party website/app combinations. E.g. if HN implemented "email auth links", there would be no way for any third-party HN reading apps to authenticate a user.
- dkopi 10y ago
  Interesting use case. I'm really enjoying this discussion. I'm guessing this could be solved if 3rd Party apps register to handle "news.ycombinator.com" links. I don't think there's any enforcement by apple or google that you actually own the domain.
  - stephenr 10y ago
    There specifically is enforcement by Apple with the new Universal Links feature (which that auth0 article talks about) Without the enforcement, it's arguably not secure unless the user is prompted "do you want to open this link in Xyz.app" With the enforcement (you have to upload a special file to web server(s) for the domain(s) you want to "claim" for your app) third party's cannot have the same level of integration (which is not limited to just auth - I'd love Twitter links to open in by native, non official client) Honestly I think the "solution" already exists and just needs polish: - Better password managers built in to browsers/os's - MUCH better handling of private keys and client certs on user devices (add client cert syncing via iCloud Keychain for example) - wider knowledge and use of 2fa systems

by dkopi 10y ago

stephenr 10y ago

That only works for first-party website/app combinations. E.g. if HN implemented "email auth links", there would be no way for any third-party HN reading apps to authenticate a user.

dkopi 10y ago
Interesting use case. I'm really enjoying this discussion. I'm guessing this could be solved if 3rd Party apps register to handle "news.ycombinator.com" links. I don't think there's any enforcement by apple or google that you actually own the domain.
- stephenr 10y ago
  There specifically is enforcement by Apple with the new Universal Links feature (which that auth0 article talks about) Without the enforcement, it's arguably not secure unless the user is prompted "do you want to open this link in Xyz.app" With the enforcement (you have to upload a special file to web server(s) for the domain(s) you want to "claim" for your app) third party's cannot have the same level of integration (which is not limited to just auth - I'd love Twitter links to open in by native, non official client) Honestly I think the "solution" already exists and just needs polish: - Better password managers built in to browsers/os's - MUCH better handling of private keys and client certs on user devices (add client cert syncing via iCloud Keychain for example) - wider knowledge and use of 2fa systems