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.
"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."
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).
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).
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 :)
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.
Assuming you have middleware that validates your JWT and sets claims on some type of user principal in memory before processing the rest of the api, why not just create the restricted claim in the middleware if there is no auth bearer in the request?
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.
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.
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?
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.
> 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.
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.
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.
Assuming 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.
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)
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?
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.
> 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.
> the revoked set is smaller than the full set of active tokens so maybe that is a win
Yeah, it seems to me the difference between having a revocation / blacklist and a non-JWT based sessions isn't the number of queries to a redis cache, since each request to the resource server will result in a check first. It's the in-memory size of the cache.
I think that clears up my question about the benefits of using JWT. Thanks! :)
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 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.
CORS isn’t bad practice. It is supported on all major browsers, and more and more APIs are supporting it. In fact, if you have a public resource that is not behind a firewall, it is safe to put the Access-Control-Allow-Origin: * header on the resource.
But there is some confusion over the role of CORS on a server. CORS should only dictate the cross-origin policy for a particular resource. In other words, the CORS headers are only meant to indicate whether requests from different origins are allowed. I think the confusion comes in because servers sometimes use CORS to dictate security policy as well. CORS is not security. If servers have resources that need to be protected from certain users, it is not safe to rely solely on the Origin header to enforce this. Your server needs some other mechanism for security (such as OAuth2 and CSRF protection).
In short, CORS is not about security of the server. And it is not even considered a whole security for end-users but about the preventing your server from misusing your clients’ “WebOS” resources by your 3rd party affiliates (advertisers), and pretty much nothing else.
Yes. 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.
your 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 :)
As one who develops IDS/IPS for 23 years, it isn’t a “dangerous” issue, per se. It’s a “muddle” issue that runs contravenous to that “be liberal in what you receive, and conservative in what you send.” Like “exec” is for JavaScript.
