The information on `/login` should probably be on / so I can read somewhere what "Stateless authentication microservice" actually means.

Also maybe a sentence why this is neat and should be used...

"Stateless authentication microservice" has only one possible meaning to me. Did you want to ask something more specific, or do you just not know what those (common) words mean?

The me it means... nothing specific.

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.

Those words have one meaning each.

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.

Obviously it comes from you being so much smarter than me.

Would be great if you could create an issue and write some more details about your requirement.

Does "put information about the service on the front page" really require a ticket?

It doesn't.

Asking to do a pull request or create an issue is just a polite way of saying fuck off.

Nope, but a ticket helps them track it, helps make your request more durable, more likely to be developed into a higher resolution of detail, and ultimately more likely to be fulfilled.

Thanks, but I know what trouble tickets are.

A response to request for detail with a request for detail...

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.

I actually didn't know that the repo also includes the website (in `/example/nextjs/pages/index.js`) that was linked here.

There you go: https://github.com/lipp/login-with/issues/25

So what's exactly the use case for this? I'm not entirely sure.

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?

It's helpful if you want your website/webapp to support login with X (Google, Facebook, etc). Your services on the same domain can than use these credentials and eventually use the respective API's with the per-user key.

All you need to do is: a) get key/secret for the respective service b) deploy this microservice with the respective env variables

This kind of explanation would be really useful on the website. Right now it has nothing to describe what it is/does.

The explanation you replied to didn't say anything I didn't find obvious from the tag line.

Aha. So it protects the service via protecting the domain itself, right?

I'll have to give it a try.

"On successful login two cookies will be created:

    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" name

" This looks like just enough rope to hang oneself. If you check only the profile variable it could easily be set by the user herself. So I guess you need to check the jwt. I guess it makes more sense if this would be run as reverse proxy so the cookies can't be tampered with.

The JWT is signed (see LW_JWT_SECRET env variable), you'll want to check the signature before trusting the rest of the contents.

Pet gripe: don't say "JWT tokens", it's just "JWT". That's what the T stands for..

True. It's a bad habit I guess.

I found the GitHub link to contain a lot of useful info about what this is: https://github.com/lipp/login-with

Very nice work!

This is really cool. I was looking for something like this a few days ago for a side project. Great job!

THX!

https://github.com/bitly/oauth2_proxy is a good one as well.

How does it handle revoked and expired sessions?

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.

Expired can happen clientside, just check the timestamp. Revoked would be a short blacklist that lasts the duration of the session, once a token is expired it no longer has to be revoked.

But I'm also curious how a revoked list would be handled with this service.

That's only true if you do not allow for long running sessions which are commonplace today. And it still requires a lookup every time to see if a particular session is blacklisted.

From what I could grasp there's no mechanics for blacklists/revocations in the current implementation of this service.

Could be useful in my current project, but I need LinkedIn also.

Created an issue https://github.com/lipp/login-with/issues/21

:)

linked in is now available and demo is online.

https://github.com/lipp/login-with/pull/31

I cannot wait to allow a bazillion fake Twitter and FB accounts from the Eastern Bloc countries to pour into my website and bigly MAGA. Thanks, social sign-on!

What's stopping people from creating fake accounts without social logins?

Administrators and community moderation who pay attention to their own access logs rather than ambiguous Facebook Review Teams who look the other way.

It's much easier for a spammer to get through your own implementation of spam filtering than through Facebook's or Google's.

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.

There's nothing stopping admins or mods from policing people who happen to use social login.

Except that they don't.

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.

I don't see how this comment is in any way useful, insightful, or constructive here.