What I do want from a login-service: authenticated users should return a public+private-key. I do not care about the login-provider, as long as I get a users pecific public+private key, as that is the thing I need for distributed untrusted apps.
The idea is to implement this as a separate service, that decouples getting a keypair from login-method and login-provider.
The service itself has two functionalities:
- Provide public/private key for authenticated users.
- Provide meta-data given a public key, ie. – reply whether public-key actually represent a verified user
The API from the application point of view is simple:
- Redirect the user to the login-service website, and after the login, the user will be redirected back to the app, an api-key in the hash, that can be used to retrieve the public/private-key.
- REST endpoint for getting the public/private-key given an api-key
- REST endpoint for getting meta data given the public key
The difficult part is the plethora of login-providers and methods. The nice thing here is that the application itself does not have to know anything about those. Possible methods of login includes:
- Unverified username/password
- Verified email
- Verified sms
- Central authority / oauth etc.: github, linkedin, twitter, facebook, google, …
- Local site, ie.: tinkuy, local wordpress, …
- Actual key, etc.