5 ms·

> Relatively easy for family and friends to use > This means keep one login per person, ideally with SSO, for as many services as I can Truly S-tier target. I

> Relatively easy for family and friends to use > This means keep one login per person, ideally with SSO, for as many services as I can Truly S-tier target. Incredible hard, incredible awesome. I've said for a long time that Linux & open source is kind of a paradox. It goes everywhere, it speaks every protocol. But as a client, as an end. The whole task of coordinating, of groupwareing, of bringing together networks: that's all much harder, much more to be defined. Making the many systems work together, having directory infrastructure: that stuff is amazing. For years I assumed that someday I'd be running FreeIPA or some Windows compatible directory service, but it sort of feels like maybe some OpenID type world might possibly be gel'ing into place.

Abishek_Muthian 1y ago
I completely agree with the paradox, just yesterday I posted how FOSS is not accessible to non-techies on my problem validation platform[1]. I've been thinking if a platform which connects techies to non-techies can help solve that, say like a systems integrator for individuals. [1] https://needgap.com/problems/484-foss-are-not-accessible-to-non-techies-opensource-techsupport https://needgap.com/problems/484-foss-are-not-accessible-to-...
- udev4096 1y ago
  It's not supposed to be. You put in time, use your brain to understand the system. Even a non-techie can easily understand OIDC and Oauth2, it's not that hard
  - nativeit 1y ago
    This seems like a very naive perspective.
  - Thorrez 1y ago
    As a techie, experienced in security, reading the OIDC spec... there are definitely some things I don't understand in there. I'm not sure the authors even understand what's going on. On 2023-12-15 they published an update to OpenID Connect Core 1.0, called "errata set 2". Previously it said to verify an ID token in a token response, the client needs to > * If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present. > * If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value. The new version is quite different. Now it says > * If the implementation is using extensions (which are beyond the scope of this specification) that result in the azp (authorized party) Claim being present, it SHOULD validate the azp value as specified by those extensions. > * This validation MAY include that when an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value. So core parts of the security of the ID Token are being changed in errata updates. What was the old purpose of azp? What is the new purpose of azp? Hard to tell. Did all the OIDC implementations in existence change to follow the new errata update (which didn't update the version number)? I doubt it. https://openid.net/specs/openid-connect-core-1_0.html https://openid.net/specs/openid-connect-core-1_0.html https://web.archive.org/web/20231214085702/https://openid.net/specs/openid-connect-core-1_0.html https://web.archive.org/web/20231214085702/https://openid.ne... Or how about a more fundamental question: Why does the ID Token have a signature? What attack does that signature prevent? What use cases does the signature allow? The spec doesn't explain that.
    - dragonwriter 1y ago
      > Did all the OIDC implementations in existence change to follow the new errata update (which didn't update the version number)? I mean, both the old and new version (at least, the parts quoted upthread) are exclusively SHOULD and MAY with no MUST, so (assuming, for the SHOULDs, the implementer had what they felt was sufficiently good reason) literally any behavior is possible while following the spec.
    - 01HNNWZ0MV43FF 1y ago
      I think I could handle up to 20 users with `.htaccess` and just handing out passwords to my friends, actually
    - maxwellg 1y ago
      > Why does the ID Token have a signature? The ID Token can be passed from the Identity Provider to the Relying Party (RP) in a few ways. When `response_mode=id_token` is used, the ID Token can be passed in the front channel directly to the RP during a browser redirect. Since the ID Token is coming from the browser, it must be signed to ensure that a malicious actor can't tamper with it. Otherwise an actor could swap out a `sub` or an `email` claim and the RP would be none the wiser. The ID Token can also be returned from the `/token` endpoint after exchanging an authorization code. Since the `/token` endpoint is a back channel call over HTTPS, the ID Token doesn't necessarily need to be signed here to avoid tampering. The RP can trust that TLS gets the job done. However, there are substantial benefits to having it be signed: - If ID tokens were only signed sometimes, we'd have two different standards for how to construct and handle an ID Token, which would be quite confusing. - Signed ID Tokens can be passed around to assert identity to other entities within the system. For example, there are some promising draft specifications that explore exchanging ID Tokens for access tokens in other systems. This is only possible because the ID Token cannot be tampered with. https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/ https://datatracker.ietf.org/doc/draft-parecki-oauth-identit...
      - Thorrez 1y ago
        >Since the ID Token is coming from the browser, it must be signed to ensure that a malicious actor can't tamper with it. Otherwise an actor could swap out a `sub` or an `email` claim and the RP would be none the wiser. Are you referring to a login CSRF attack? Where an attacker causes a victim to visit a URL that forces the victim to log in to an account of the attacker's choosing? A signature on the token doesn't solve that AFAICT. The reason a token signature doesn't solve that is that an attacker can take the attacker's own ID Token that has a valid signature, and do the attack with that ID Token, forcing the victim to log in to the attacker's account. Yes, the token signature does reduce the attacker's ability. Without a token signature, the attacker could force the victim to log in to any account. With a token signature the attacker can only force the victim to log in to the attacker's account. But this isn't a full solution. Some other anti-CSRF mechanism needs to exist. Once that anti-CSRF mechanism exists, the token signature is no longer useful. Adding a signature to the token doesn't make sense to me as a login CSRF protection mechanism. If the designer's goal was to protect against login CSRF, the signature should be over something else, not just the token, and not part of the token. Then the token itself doesn't need the complexity of a signature (and the authorization code flow doesn't need the complexity of a signature), just the redirect flow needs it. Or even simpler, the designers could have mandated the authorization code flow, and not need any signature at all. Or maybe you're referring to a completely different attack, where there isn't a victim user, just an attacker wanting to log in as someone else in the attacker's own browser. In that case, the signature doesn't solve that attack, because since everything happens in the attacker's browser, the attacker can modify the js locally to disable signature verification. >- Signed ID Tokens can be passed around to assert identity to other entities within the system. For example, there are some promising draft specifications that explore exchanging ID Tokens for access tokens in other systems. This is only possible because the ID Token cannot be tampered with. Yes, but the spec doesn't mention this. Just from reading the spec, a reader can wonder, "why is there all this unexplained complexity for no apparent reason?"
mirdaki 1y ago
Appreciate that! Simple login and access was certainly the hardest requirement to hit, but it can be the difference between people using something and not And I agree with the feeling that open source is everywhere, up until a regular user picks up something. I think part of the paradox you mention is that every project is trying to work on their own thing, which is great, but also means there isn't a single entity pushing it all in one direction But that doesn't mean we can't get to nice user experiences. Just in the self-hosting space, things have gotten way more usable in the last 5 years, both from a setup and usage perspective
cycomanic 1y ago
It's not really that hard to be honest. If you are not dead set on specific services, but make sso compatability the main selection metric for the services it's very feasible and not that difficult. I had very little experience when I set up my self hosted system and was set up very quickly using caddy and authentik. Alternatively yunohost is a very easy to use distribution that sets up everything using SSO.
- throwup238 1y ago
  Agreed. I use Cloudflare Zero Trust for SSO authentication (I use Github for my self and Google/Apple for family) and Cloudflare Tunnels to expose homelab services behind NAT. It took an afternoon to set up the first service and adding services via IaC like terraform is easy. The only time consuming thing since then has been figuring out how to use the Cloudflare auth header to authenticate with each individual app (and many don’t have multiuser capability so it’s not a big deal).
- jauntywundrkind 1y ago
  Yuno-host doing SSO is something I deeply deeply respect & love about it! Yes! I haven't pulled it down yet to find out just how extensive the SSO is. My understanding is that it's not totally universal... But that it is like ~50%, which is super not bad given how many packages it has!
Bombthecat 1y ago
I use authentik with sso via Google, discord or GitHub. It's good enough for everyone.

Abishek_Muthian 1y ago

I completely agree with the paradox, just yesterday I posted how FOSS is not accessible to non-techies on my problem validation platform[1]. I've been thinking if a platform which connects techies to non-techies can help solve that, say like a systems integrator for individuals. [1] https://needgap.com/problems/484-foss-are-not-accessible-to-non-techies-opensource-techsupport https://needgap.com/problems/484-foss-are-not-accessible-to-...

udev4096 1y ago
It's not supposed to be. You put in time, use your brain to understand the system. Even a non-techie can easily understand OIDC and Oauth2, it's not that hard
- nativeit 1y ago
  This seems like a very naive perspective.
- Thorrez 1y ago
  As a techie, experienced in security, reading the OIDC spec... there are definitely some things I don't understand in there. I'm not sure the authors even understand what's going on. On 2023-12-15 they published an update to OpenID Connect Core 1.0, called "errata set 2". Previously it said to verify an ID token in a token response, the client needs to > * If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present. > * If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value. The new version is quite different. Now it says > * If the implementation is using extensions (which are beyond the scope of this specification) that result in the azp (authorized party) Claim being present, it SHOULD validate the azp value as specified by those extensions. > * This validation MAY include that when an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value. So core parts of the security of the ID Token are being changed in errata updates. What was the old purpose of azp? What is the new purpose of azp? Hard to tell. Did all the OIDC implementations in existence change to follow the new errata update (which didn't update the version number)? I doubt it. https://openid.net/specs/openid-connect-core-1_0.html https://openid.net/specs/openid-connect-core-1_0.html https://web.archive.org/web/20231214085702/https://openid.net/specs/openid-connect-core-1_0.html https://web.archive.org/web/20231214085702/https://openid.ne... Or how about a more fundamental question: Why does the ID Token have a signature? What attack does that signature prevent? What use cases does the signature allow? The spec doesn't explain that.
  - dragonwriter 1y ago
    > Did all the OIDC implementations in existence change to follow the new errata update (which didn't update the version number)? I mean, both the old and new version (at least, the parts quoted upthread) are exclusively SHOULD and MAY with no MUST, so (assuming, for the SHOULDs, the implementer had what they felt was sufficiently good reason) literally any behavior is possible while following the spec.
  - 01HNNWZ0MV43FF 1y ago
    I think I could handle up to 20 users with `.htaccess` and just handing out passwords to my friends, actually
  - maxwellg 1y ago
    > Why does the ID Token have a signature? The ID Token can be passed from the Identity Provider to the Relying Party (RP) in a few ways. When `response_mode=id_token` is used, the ID Token can be passed in the front channel directly to the RP during a browser redirect. Since the ID Token is coming from the browser, it must be signed to ensure that a malicious actor can't tamper with it. Otherwise an actor could swap out a `sub` or an `email` claim and the RP would be none the wiser. The ID Token can also be returned from the `/token` endpoint after exchanging an authorization code. Since the `/token` endpoint is a back channel call over HTTPS, the ID Token doesn't necessarily need to be signed here to avoid tampering. The RP can trust that TLS gets the job done. However, there are substantial benefits to having it be signed: - If ID tokens were only signed sometimes, we'd have two different standards for how to construct and handle an ID Token, which would be quite confusing. - Signed ID Tokens can be passed around to assert identity to other entities within the system. For example, there are some promising draft specifications that explore exchanging ID Tokens for access tokens in other systems. This is only possible because the ID Token cannot be tampered with. https://datatracker.ietf.org/doc/draft-parecki-oauth-identity-assertion-authz-grant/ https://datatracker.ietf.org/doc/draft-parecki-oauth-identit...
    - Thorrez 1y ago
      >Since the ID Token is coming from the browser, it must be signed to ensure that a malicious actor can't tamper with it. Otherwise an actor could swap out a `sub` or an `email` claim and the RP would be none the wiser. Are you referring to a login CSRF attack? Where an attacker causes a victim to visit a URL that forces the victim to log in to an account of the attacker's choosing? A signature on the token doesn't solve that AFAICT. The reason a token signature doesn't solve that is that an attacker can take the attacker's own ID Token that has a valid signature, and do the attack with that ID Token, forcing the victim to log in to the attacker's account. Yes, the token signature does reduce the attacker's ability. Without a token signature, the attacker could force the victim to log in to any account. With a token signature the attacker can only force the victim to log in to the attacker's account. But this isn't a full solution. Some other anti-CSRF mechanism needs to exist. Once that anti-CSRF mechanism exists, the token signature is no longer useful. Adding a signature to the token doesn't make sense to me as a login CSRF protection mechanism. If the designer's goal was to protect against login CSRF, the signature should be over something else, not just the token, and not part of the token. Then the token itself doesn't need the complexity of a signature (and the authorization code flow doesn't need the complexity of a signature), just the redirect flow needs it. Or even simpler, the designers could have mandated the authorization code flow, and not need any signature at all. Or maybe you're referring to a completely different attack, where there isn't a victim user, just an attacker wanting to log in as someone else in the attacker's own browser. In that case, the signature doesn't solve that attack, because since everything happens in the attacker's browser, the attacker can modify the js locally to disable signature verification. >- Signed ID Tokens can be passed around to assert identity to other entities within the system. For example, there are some promising draft specifications that explore exchanging ID Tokens for access tokens in other systems. This is only possible because the ID Token cannot be tampered with. Yes, but the spec doesn't mention this. Just from reading the spec, a reader can wonder, "why is there all this unexplained complexity for no apparent reason?"

mirdaki 1y ago

Appreciate that! Simple login and access was certainly the hardest requirement to hit, but it can be the difference between people using something and not And I agree with the feeling that open source is everywhere, up until a regular user picks up something. I think part of the paradox you mention is that every project is trying to work on their own thing, which is great, but also means there isn't a single entity pushing it all in one direction But that doesn't mean we can't get to nice user experiences. Just in the self-hosting space, things have gotten way more usable in the last 5 years, both from a setup and usage perspective

cycomanic 1y ago

It's not really that hard to be honest. If you are not dead set on specific services, but make sso compatability the main selection metric for the services it's very feasible and not that difficult. I had very little experience when I set up my self hosted system and was set up very quickly using caddy and authentik. Alternatively yunohost is a very easy to use distribution that sets up everything using SSO.

throwup238 1y ago
Agreed. I use Cloudflare Zero Trust for SSO authentication (I use Github for my self and Google/Apple for family) and Cloudflare Tunnels to expose homelab services behind NAT. It took an afternoon to set up the first service and adding services via IaC like terraform is easy. The only time consuming thing since then has been figuring out how to use the Cloudflare auth header to authenticate with each individual app (and many don’t have multiuser capability so it’s not a big deal).
jauntywundrkind 1y ago
Yuno-host doing SSO is something I deeply deeply respect & love about it! Yes! I haven't pulled it down yet to find out just how extensive the SSO is. My understanding is that it's not totally universal... But that it is like ~50%, which is super not bad given how many packages it has!

Bombthecat 1y ago

I use authentik with sso via Google, discord or GitHub. It's good enough for everyone.