Show HN: OAuth microservice for FB, Twitter, etc.
login-with.com
login-with.com
Also maybe a sentence why this is neat and should be used...
Asking to do a pull request or create an issue is just a polite way of saying fuck off.
Perhaps you could describe what details you would like to see in the issue? :)
---
In seriousness, noobish me would like to understand more what this is and when I should use it.
There you go: https://github.com/lipp/login-with/issues/25
It tells me that is has something to do with login, "without state" (whatever this means in this context) and that it is somehow not a "big service" but very "micro", so probably independent. Stateless and microservice can mean so many things.
A microservice is a service that does only one thing, and does it simply.
Something stateless doesn't keep state - after an interaction with a client, nothing has changed in the service itself.
A stateless authentication microservice is something I would expect to run, listen on a port for some sort of authentication credentials, and return either some sort of authorizarion token or an authentication error.
I don't see where the confusion comes from.
Let's say I deploy it. Users of whatever service I provide use this to login to Google, Twitter, etc, then what? do I need to also implement something on the servers I'm protecting behind a login? I.e. some "verification" method that checks whether the client's JWT tokens are valid so I can grant them access?
All you need to do is: a) get key/secret for the respective service b) deploy this microservice with the respective env variables
I'll have to give it a try.
jwt - A "JSON Web Token" (JWT) containing profile information and the respective access tokens (Twitter/etc). http-only!
profile - A JSON string which containing non-sensitive information (accessible from browser JS):
username - string / mandatory, the account specific user alias (e.g. Twitter name) - photo - string / optional, the account specific user image link
name - string / optional, the "real" nameVery nice work!
From my prior research this seems to be a problem with the JWT which would either require distribution of ever growing blacklists or session verification through shared server side sessions.
Would also love to see some API documentation.
I really like the idea and always reimplementing login services seems like unnecessary hassle.
But I'm also curious how a revoked list would be handled with this service.
From what I could grasp there's no mechanics for blacklists/revocations in the current implementation of this service.
:)
Account identity and authentication being outsourced to Facebook means your community maintainers don't get to notice the fact that those 100 MAGA-spouting dimwits are from Romania. They don't get that information in the first place.
Do you think you can implement automatic ip black listing, phone confirmation and better spammy account categorizers based on common spam signals than the big players, who have dedicated research teams working on this? I know I can't and even if I could, I'd rather spend my dev time on tasks related to the core business.