
Loginsrv: JWT login microservice with back ends like OAuth2, Google, GitHub - networked
https://github.com/tarent/loginsrv
======
korijn
Awesome! Are there any other open source microservices fulfilling similar
purposes? I've been looking all over the place. I decided to go with keycloak
and keycloak-gatekeeper after failing to find anything less heavy weight.

~~~
noodlesUK
Take a peek at the ORY stack

~~~
emmelaich
[https://www.ory.sh/](https://www.ory.sh/)

" _Open Source Identity Infrastructure and Services Run User Management,
Permission and Role Management, and OAuth 2.0 & OpenID Connect anywhere from
your cloud to a Raspberry Pi._"

~~~
jadbox
How does it compare to Loginsrv?

~~~
emmelaich
Sorry, I know nothing about it; just trying to save others websearch time.

------
buro9
This is wonderful.

If a passwordless option was available too, i.e. email a TOTP code that is a
nonce, and presentation of the TOTP would generate a JWT with the email
address as the claim... then this would become my new login manager.

I'm presently using auth0 free plan. Which is nice, but passwordless lock
(their JS library) is old, and their docs are not great as to how to update to
their other lock library (I've concluded you can't stay passwordless with the
main auth0 lock library).

~~~
_puk
Something similar I've wanted before, but auth0 didn't support, is the
provision of anonymous tokens. No need for them to persist.

Controlling non logged in user claims / access without having to have special
"no token" caveats or endpoints (i.e. any user can have read access to an
endpoint, but only if they have a token / have come via your website).

Is anything like this supported anywhere?

~~~
abhishektwr
Can you explain bit more about your use case? You meant to say a just access
token but no id token or session?

~~~
_puk
Being able to create an anonymous access token, that in turn has certain
restricted claims defined by default.

API keys kind of do the job, but they're basically deprecated through a lot of
JWT providers, and you need to support two Auth systems if you're using JWT
for logged in users.

Flow is:

* Arrive at website * Generate an access token without any user input (anon user with default read only privileges) * Use the same APIs as logged in users, with restricted access defined in the JWT / Auth provider.

The two sides of it, am I allowed to access this API, coupled with what can I
do once accessed seem to be the basic use case for JWT.

I appreciate the response. My terminology is likely a bit off, it's been a
while :)

~~~
abhishektwr
Assuming you are using traditional web app and not SPA, I think it’s
absolutely possible to generate restricted access tokens for anonymous users
either using Machine to machine (M2M) client authentication or service account
(SA) client authentication basically without any user context. Many Identity
as a service providers supports M2M, and platform I am in involved supports
both M2M/SA (disclaimer in profile). You can effectively attach an anonymous
role to your OAuth client of type M2M/SA and start issuing access tokens. For
SPA it could be complicated.

------
gavinray
I was looking through the examples, it seems like there isn't a way to use
this out-of-the-box with an API service that does "/login" and "/signup" by
password hash and compare:

\- Htpasswd (Dedicated credentials file)

\- Simple (user/password pairs by configuration)

\- Httpupstream (HTTP API Basic auth configuration)

It mentions "OSIAM" which I'm not familiar with.

Is there a way to use this to "enhance" a basic JWT auth server implementation
that does a bcrypt/Argon2 hash or hash comparison on password with these
social-sign-on OAuth providers?

Or any similar library, that would be really useful.

------
TechBro8615
Looks cool. FYI, the "sign in with google" button breaks the google branding
guidelines [0]. You must use the colored G logo and it must be on a white
background.

[0] [https://developers.google.com/identity/branding-
guidelines](https://developers.google.com/identity/branding-guidelines)

~~~
renke1
Those branding guidelines are formulated vaguely in my opinion: What colors
are allowed for certain button states (hover, focus, etc)? Do I really have to
use Roboto? etc.

The assets are also not a good foundation to build a customized (yet
compliant) button.

I've also seen so many buttons that cannot possibly be compliant without those
guidelines, but Google doesn't seem to care, do they?

------
m12k
I'm a bit surprised the project is called loginsrv, yet the example buttons
say "Sign in with X" instead of "Log in with X". I thought the UX world had
more or less consolidated around 'Log in' and 'Sign up', to make the two
options as visually distinct at a glance as possible.

~~~
johnhenry
> I thought the UX world had more or less consolidated around 'Log in' and
> 'Sign up', to make the two options as visually distinct at a glance as
> possible.

Honest question: what gave you that impression?

------
zemnmez
would always recommend the standard id_token form for any authentication JWTs
[https://openid.net/specs/openid-connect-
core-1_0.html#IDToke...](https://openid.net/specs/openid-connect-
core-1_0.html#IDToken)

------
satvikpendem
Nice, this is like an open-source Firebase Authentication. I was wondering
whether such a solution existed because, even as Firebase Auth is free for
unlimited users, it still is a hosted service whose terms could change at any
time.

------
bhl
How do Oauth2 providers like Google and Github handle password resets or stale
data with JWT tokens? Curious because I was trying to implement JWT for auth,
but might switch to sessions now.

~~~
blahbhthrow3748
You basically need to have a revocation list or rely on the expiration time
being sufficiently short. JWTs are neat for a lot of things but I don't think
they make sense as a replacement for sessions for that reason (where you
control the server and the client and you want to authenticate users)

~~~
magicalhippo
Isn't that the point of the refresh tokens? Auth token is short lived, so you
get a new one using the refresh token without getting the user involved. But
then that gives the auth server a means to deny that request if the user has
revoked access?

Or am I misremembering?

~~~
trebecks
yeah, that is what refresh tokens are used for and it works well for access
tokens with a short ttl. in practice i have seen access tokens with ttl of a
few hours. i think it might be done to cut down on the refresh calls? in that
case, if you want to deny requests with a revoked token sooner than the
potentially few hours it takes for it to expire, you could keep the set of
revoked tokens server side.

that feels like a weird place to be in with server side state for stuff that
is supposed to be stateless. i guess the revoked set is smaller than the full
set of active tokens so maybe that is a win? curious if anyone has experience
with this.

~~~
magicalhippo
> in practice i have seen access tokens with ttl of a few hours

The JWT tokens we get for m2m from Maskinporten[1] have a TTL of a couple of
minutes.

No refresh tokens though, I guess they figure it doesn't make much difference
since the "user" is a machine so no hassle just sending a full request again.

[1]:
[https://difi.github.io/felleslosninger/maskinporten_protocol...](https://difi.github.io/felleslosninger/maskinporten_protocol_jwtgrant.html)

------
miohtama
This looks brilliant. I could see loginsrv as a drop-in replacement for SaaS
product offering the same functionality, like Xsolla.

------
johnx123-up
Will it support LDAP in the near future?

------
dk8996
How does this compare to AWS Cognito?

~~~
olliepop
This is open-source, requires self-hosting, is free... There really isn't
anything to compare.

------
yoanndefay
yea would be awesome if you could put it in a cloudflare worker

~~~
hendry
[https://teams.cloudflare.com/access](https://teams.cloudflare.com/access) I
think is Cloudflare's identity solution. 3$ a user though. haha

------
egberts1
Mmmm, it’s uses JWT. That went out the window, for me.

My checklist: [https://egbert.net/blog/articles/authentication-for-
api.html](https://egbert.net/blog/articles/authentication-for-api.html)

~~~
eganist
egberts1, can you please share your reasons for "DO NOT use JWT"? The citation
on your blog only links to the wikipedia page
[https://en.wikipedia.org/wiki/JSON_Web_Token](https://en.wikipedia.org/wiki/JSON_Web_Token)
rather than a resource describing any issues with JWTs specifically.

...I also have to wonder why no CORS. When properly managed (e.g. static-
whitelisted allowed origins + allowed credentials from/to dedicated domains)
and combined with other best practices around your web SSO framework of
choice, it's fine for contexts such as SSO with no back-end sync.

~~~
michaelchisari
I can't speak for egberts1, but Thomas Ptacek(@tptacek) has written a lot on
why JWTs should be avoided.

Here's an HN search for his comments on JWTs:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=author%3Atptacek%20jwt&sort=byDate&type=comment)

Here is one of his comments about JWT:

 _In cryptography, we have a concept of "misuse resistance"._

[https://news.ycombinator.com/item?id=14292223](https://news.ycombinator.com/item?id=14292223))

~~~
toomuchtodo
The comment you link to is gold. Thank you.

