6 ms·
Loginsrv: JWT login microservice with back ends like OAuth2, Google, GitHub
- TechBro8615 6y agoLooks 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 6y agoThose 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?
- miohtama 6y agoThis looks brilliant. I could see loginsrv as a drop-in replacement for SaaS product offering the same functionality, like Xsolla.
- korijn 6y agoAwesome! 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.
- tlarkworthy 6y agoI made one myself for internal gsuite auth https://futurice.com/blog/identity-aware-proxy-for-google-cloud-run https://futurice.com/blog/identity-aware-proxy-for-google-cl... There is a branch with slack integration in progress ATM
- yannikyeo 6y agoThis post appears while I was searching just now for similar tools and come across FusionAuth and Keratin Authn. Not yet look into the details.
- noodlesUK 6y agoTake a peek at the ORY stack
- emmelaich 6y agohttps://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."
- GrantZvolsky 6y agoIf you package one of the IdentityServer4[1] quickstarts with e.g. Docker you'll get a comparable result. [1]: https://github.com/IdentityServer/IdentityServer4 https://github.com/IdentityServer/IdentityServer4
- gavinray 6y agoI 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.
- egberts1 6y agoMmmm, 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 6y agoegberts1, 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.
- jugg1es 6y agoyea there is zero justification in your blog - just references to pages describing the technology. I would be interested to know what the rational is.
- egberts1 6y agoYes. That is true what you’ve said. Sometime, with waves of web pages, coupled with the analytical thoughts of weakness in each leg of a protocol, I should have explicitly noted them. In this case, I was in a hurry to put it down. Better to document what I’ve noticed and find justification later. My bad.
- egberts1 6y agoSo, I’ve added more on CORS in earlier thread under this GP.
- jugg1es 6y agoyour rationale leaves something to be desired. I don't know if its really valid to consider something a dangerous tech just because it can be misused. Your computer can be very dangerous if misused - such as if you drop it out of a window on someone's head - that doesn't mean you shouldn't use a computer :)
- bhl 6y agoHow 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.
- bojanz 6y agoAssuming that the JWT only stores the user_id, and you then load the full user (protecting against stale data), a counter or a timestamp on the user object can be used to control logout. There's a good Go library detailing this approach, along with a blog post: https://github.com/endiangroup/compandauth https://github.com/endiangroup/compandauth https://endian.io/articles/compandauth/ https://endian.io/articles/compandauth/
- blahbhthrow3748 6y agoYou 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 6y agoIsn'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 6y agoyeah, 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.
- dk8996 6y agoHow does this compare to AWS Cognito?
- olliepop 6y agoThis is open-source, requires self-hosting, is free... There really isn't anything to compare.
- zemnmez 6y agowould always recommend the standard id_token form for any authentication JWTs https://openid.net/specs/openid-connect-core-1_0.html#IDToken https://openid.net/specs/openid-connect-core-1_0.html#IDToke...
- yoanndefay 6y agoyea would be awesome if you could put it in a cloudflare worker
- hendry 6y agohttps://teams.cloudflare.com/access https://teams.cloudflare.com/access I think is Cloudflare's identity solution. 3$ a user though. haha
- m12k 6y agoI'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 6y ago> 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?
- buro9 6y agoThis 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 6y agoSomething 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 6y agoCan you explain bit more about your use case? You meant to say a just access token but no id token or session?
- _puk 6y agoBeing 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 :)
- 6y ago
- johnx123-up 6y agoWill it support LDAP in the near future?
- satvikpendem 6y agoNice, 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.