6 ms·

Cool to see such a comprehensive guide! At the same time, are people seriously still pushing OAuth2 for first party auth? Shouldn’t everyone know by one that OA

Cool to see such a comprehensive guide! At the same time, are people seriously still pushing OAuth2 for first party auth? Shouldn’t everyone know by one that OAuth does not solve: * registration * account recovery * profile management * 2fa * … and is generally completely overblown for first party auth? I always to cite from the abstract of the OAuth2 RFC: > The OAuth 2.0 authorization framework enables a *third-party* application to obtain limited access to an HTTP service Yet somehow all of these proprietary software companies (FusionAuth, Auth0, …) cling to the only „open protocol“ to push „portability“ of protocols. But the problem of portability is really a problem of data (you user’s data and migrating that data from system A to B), not the way you exchange or validate tokens or cookies. I think it’s exciting to see new open source projects like https://github.com/ory/kratos https://github.com/ory/kratos or https://github.com/supertokens/supertokens-core https://github.com/supertokens/supertokens-core that finally break up this misconception!

athyuttamre 5y ago
Hey keephand, I’m working on a project that tries to solve first party auth in a more intuitive way (and doesn’t use OAuth). I’d love to chat more. Don’t see a way to reach you in your bio; if you’re open to it, could you reach out to the email in my profile?
Jenk 5y ago
It works really well for scaling your systems. In the case of "third party" this can mean disparate services within your platform, permitting you to fully isolate the authentication from literally everything else.
- keephand 5y ago
  Sorry but that’s just wrong. The biggest auth systems in the world (Google, Amazon, Microsoft) do not rely on OAuth2 for internal services. Isolating auth into a central service and acquiring user consent as a third party, which very literally is the only purpose of OAuth2, are two very different things. Saying that you need a third party delegation tool to „scale“ an auth system is like saying that you need a good combustion engine to build an electric car.
  - dwaite 5y ago
    Google and Microsoft do use OpenID Connect for internal services, as well as their consumer-facing services. While they do not necessarily use consent for delegation, they do use automated policies to restrict API access to what the application needs. Likewise, having a common protocol for getting authentication and API access allows them to decompose systems. Having to build first party authentication and API access systems would naturally encourage applications to become monolithic.
  - Jenk 5y ago
    You are wrong. You do not need to acquire consent, either, when it is implicitly granted because the service is the same system as the IdP. I.e., consent is requested/granted when they sign up with your IdP.
moonchrome 5y ago
I think a bunch of frameworks already have support for JWT validation and OIDC/OAuth in Auth middleware. Also everyone used it at some point. So might as well use something that's there and known and will scale.
- keephand 5y ago
  JWT is not OAuth2. In fact, OAuth2 shouldn’t even use JWTs in the first place. For example, all big systems (Google, Amazon, Microsoft) use opaque tokens for OAuth2 (in third party contexts) due to revokation, PII, and other concerns. Complexity doesn’t scale if used in the wrong context. And needing to put a nail in the wall (pass by value tokens) justifies buying a hammer (JWT) but not a chainsaw (OAuth)
  - mooreds 5y ago
    Actually, many vendors use JWTs as the OAuth tokens, though they don't have to. And they are required by OIDC. There's a standard for using JWTs as OAuth tokens, though it is a new one that may not be well supported yet: https://datatracker.ietf.org/doc/html/rfc9068 https://datatracker.ietf.org/doc/html/rfc9068
    - dwaite 5y ago
      > Actually, many vendors use JWTs as the OAuth tokens, though they don't have to. And they are required by OIDC. Clarification - only the id_token defined by OIDC needs to be a JWT. This is because it is an authentication statement to the client, so the client needs to be able to verify and understand the data.
      - mooreds 5y ago
        Fair point. I didn't realize that the access token was referenced in the OIDC spec, but sure enough, there it is: "After receiving and validating a valid and authorized Token Request from the Client, the Authorization Server returns a successful response that includes an ID Token and an Access Token" https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse https://openid.net/specs/openid-connect-core-1_0.html#TokenR...
deleted 5y ago
[deleted]
fuzzy2 5y ago
“People” don’t want first-party authentication and accounts. With OAuth2 (or rather OpenID Connect) it’s ridiculously trivial to get started with third-party auth (not really third-party but “auth as a service”). This isn’t about portability at all. Sure you’ll regret it later as new requirements regarding auth as requirements about the flow and page design and whatnot keep coming. However, you have to admit that it’s very tempting. Ready-to-use OIDC/OAuth2 adapters exist for just about anything. Decision-makers and customers can rarely grasp the consequences, but they certainly see the immediate cost-savings.
rad_gruchalski 5y ago
Integrating Kratos with anything is just so much work. The only nice thing differentiating Kratos from Keycloak is the ability to provide your own UI out of bound. In Keycloak, one has to use the template language provided by Keycloak and embed all those templates in a JAR file, which can be an operational hassle. Kratos makes it nice because it decouples the registration/login/recovery/settings flows from the UI but wow - integrating it even with Hydra is a mess. I mean, look at a simple case of passing your subject info to hydra token. There's a dedicated admin API in Hydra for that. In practice, I still find Keycloak more ergonomic because it comes with batteries included and it also provides authorization services. I've written more about those here: https://gruchalski.com/posts/2020-09-05-introduction-to-keycloak-authorization-services/ https://gruchalski.com/posts/2020-09-05-introduction-to-keyc....
mooreds 5y ago
I agree that OAuth by itself doesn't solve registration, account recovery, profile management, 2fa, etc. Most OAuth2 servers (whether the ones you mention or others like keycloak, identity server, azure ad b2c, ping identity, etc, etc) augment the standard with this functionality. Other than OIDC for authentication, I am not aware of any other high level standards for these problems (though https://datatracker.ietf.org/doc/html/rfc6238 https://datatracker.ietf.org/doc/html/rfc6238 is useful for 2fa). I think that software companies push OAuth2 because it solves a real problem and is a standard. If there are other standards around identity, they'll also be used by these folks (SCIM, other OAuth grants). If there are holes in functionality, those will be filled by custom implementations (whether the software is OSS or not). I don't see how those open source projects that you mention get us closer to data portability. Can you explain that? FYI, both FusionAuth and Auth0 allow exports of password hashes, which is fundamental to letting the data owner migrate easily. Disclosure: I work for FusionAuth.
dwaite 5y ago
> Cool to see such a comprehensive guide! At the same time, are people seriously still pushing OAuth2 for first party auth? Shouldn’t everyone know by one that OAuth does not solve... I assume you are using "Auth" for authentication, and not authorization (as OAuth does). Indeed, OAuth does zero for first or third party authentication of users - authentication is a set of extensions provided by OpenID Connect. The reason people use OpenID Connect as the API for first party authentication is because you _need_ an API for integrating externalized authentication systems, and (excluding SAML) every other system is proprietary with minimal cross-vendor support. However, that OpenID Connect API only provides for authentication with a few (possibly supported) hints for behavior. It is up to the OpenID Provider software to provide all the IAM features you mention - registration, account recover, profile management, multi-factor authentication, etc. There is no standard for registration, account recovery, profile management, or MFA because all of these are business processes or user experience customizations - they are software, not protocols. That is why OpenID Connect is used to integrate with a piece of off-the-shelf software which implements your business policy and which is customized for your desired experience. At most, you see things like https://github.com/w3c/webappsec-change-password-url https://github.com/w3c/webappsec-change-password-url - website configuration to tell a password manager where to navigate the browser in order to change the user's password. > I think it’s exciting to see new open source projects like https://github.com/ory/kratos https://github.com/ory/kratos or https://github.com/supertokens/supertokens-core https://github.com/supertokens/supertokens-core that finally break up this misconception! These both have the same architecture as say an Auth0. Supertokens API provides a proprietary alternative to a constrained OpenID Connect protocol. Kratos has a companion project which exposes the server via OpenID Connect. The supertokens API may have been easier for _them_ to implement than all of the potential OAuth and OpenID Connect extensions, but when going with constrained profiles like the OpenID Connect Basic Client Profile it would be difficult to be substantially simpler without being less secure.

athyuttamre 5y ago

Hey keephand, I’m working on a project that tries to solve first party auth in a more intuitive way (and doesn’t use OAuth). I’d love to chat more. Don’t see a way to reach you in your bio; if you’re open to it, could you reach out to the email in my profile?

Jenk 5y ago

It works really well for scaling your systems. In the case of "third party" this can mean disparate services within your platform, permitting you to fully isolate the authentication from literally everything else.

keephand 5y ago
Sorry but that’s just wrong. The biggest auth systems in the world (Google, Amazon, Microsoft) do not rely on OAuth2 for internal services. Isolating auth into a central service and acquiring user consent as a third party, which very literally is the only purpose of OAuth2, are two very different things. Saying that you need a third party delegation tool to „scale“ an auth system is like saying that you need a good combustion engine to build an electric car.
- dwaite 5y ago
  Google and Microsoft do use OpenID Connect for internal services, as well as their consumer-facing services. While they do not necessarily use consent for delegation, they do use automated policies to restrict API access to what the application needs. Likewise, having a common protocol for getting authentication and API access allows them to decompose systems. Having to build first party authentication and API access systems would naturally encourage applications to become monolithic.
- Jenk 5y ago
  You are wrong. You do not need to acquire consent, either, when it is implicitly granted because the service is the same system as the IdP. I.e., consent is requested/granted when they sign up with your IdP.

moonchrome 5y ago

I think a bunch of frameworks already have support for JWT validation and OIDC/OAuth in Auth middleware. Also everyone used it at some point. So might as well use something that's there and known and will scale.

keephand 5y ago
JWT is not OAuth2. In fact, OAuth2 shouldn’t even use JWTs in the first place. For example, all big systems (Google, Amazon, Microsoft) use opaque tokens for OAuth2 (in third party contexts) due to revokation, PII, and other concerns. Complexity doesn’t scale if used in the wrong context. And needing to put a nail in the wall (pass by value tokens) justifies buying a hammer (JWT) but not a chainsaw (OAuth)
- mooreds 5y ago
  Actually, many vendors use JWTs as the OAuth tokens, though they don't have to. And they are required by OIDC. There's a standard for using JWTs as OAuth tokens, though it is a new one that may not be well supported yet: https://datatracker.ietf.org/doc/html/rfc9068 https://datatracker.ietf.org/doc/html/rfc9068
  - dwaite 5y ago
    > Actually, many vendors use JWTs as the OAuth tokens, though they don't have to. And they are required by OIDC. Clarification - only the id_token defined by OIDC needs to be a JWT. This is because it is an authentication statement to the client, so the client needs to be able to verify and understand the data.
    - mooreds 5y ago
      Fair point. I didn't realize that the access token was referenced in the OIDC spec, but sure enough, there it is: "After receiving and validating a valid and authorized Token Request from the Client, the Authorization Server returns a successful response that includes an ID Token and an Access Token" https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse https://openid.net/specs/openid-connect-core-1_0.html#TokenR...

deleted 5y ago

[deleted]

fuzzy2 5y ago

“People” don’t want first-party authentication and accounts. With OAuth2 (or rather OpenID Connect) it’s ridiculously trivial to get started with third-party auth (not really third-party but “auth as a service”). This isn’t about portability at all. Sure you’ll regret it later as new requirements regarding auth as requirements about the flow and page design and whatnot keep coming. However, you have to admit that it’s very tempting. Ready-to-use OIDC/OAuth2 adapters exist for just about anything. Decision-makers and customers can rarely grasp the consequences, but they certainly see the immediate cost-savings.

rad_gruchalski 5y ago

Integrating Kratos with anything is just so much work. The only nice thing differentiating Kratos from Keycloak is the ability to provide your own UI out of bound. In Keycloak, one has to use the template language provided by Keycloak and embed all those templates in a JAR file, which can be an operational hassle. Kratos makes it nice because it decouples the registration/login/recovery/settings flows from the UI but wow - integrating it even with Hydra is a mess. I mean, look at a simple case of passing your subject info to hydra token. There's a dedicated admin API in Hydra for that. In practice, I still find Keycloak more ergonomic because it comes with batteries included and it also provides authorization services. I've written more about those here: https://gruchalski.com/posts/2020-09-05-introduction-to-keycloak-authorization-services/ https://gruchalski.com/posts/2020-09-05-introduction-to-keyc....

mooreds 5y ago

I agree that OAuth by itself doesn't solve registration, account recovery, profile management, 2fa, etc. Most OAuth2 servers (whether the ones you mention or others like keycloak, identity server, azure ad b2c, ping identity, etc, etc) augment the standard with this functionality. Other than OIDC for authentication, I am not aware of any other high level standards for these problems (though https://datatracker.ietf.org/doc/html/rfc6238 https://datatracker.ietf.org/doc/html/rfc6238 is useful for 2fa). I think that software companies push OAuth2 because it solves a real problem and is a standard. If there are other standards around identity, they'll also be used by these folks (SCIM, other OAuth grants). If there are holes in functionality, those will be filled by custom implementations (whether the software is OSS or not). I don't see how those open source projects that you mention get us closer to data portability. Can you explain that? FYI, both FusionAuth and Auth0 allow exports of password hashes, which is fundamental to letting the data owner migrate easily. Disclosure: I work for FusionAuth.

dwaite 5y ago

> Cool to see such a comprehensive guide! At the same time, are people seriously still pushing OAuth2 for first party auth? Shouldn’t everyone know by one that OAuth does not solve... I assume you are using "Auth" for authentication, and not authorization (as OAuth does). Indeed, OAuth does zero for first or third party authentication of users - authentication is a set of extensions provided by OpenID Connect. The reason people use OpenID Connect as the API for first party authentication is because you _need_ an API for integrating externalized authentication systems, and (excluding SAML) every other system is proprietary with minimal cross-vendor support. However, that OpenID Connect API only provides for authentication with a few (possibly supported) hints for behavior. It is up to the OpenID Provider software to provide all the IAM features you mention - registration, account recover, profile management, multi-factor authentication, etc. There is no standard for registration, account recovery, profile management, or MFA because all of these are business processes or user experience customizations - they are software, not protocols. That is why OpenID Connect is used to integrate with a piece of off-the-shelf software which implements your business policy and which is customized for your desired experience. At most, you see things like https://github.com/w3c/webappsec-change-password-url https://github.com/w3c/webappsec-change-password-url - website configuration to tell a password manager where to navigate the browser in order to change the user's password. > I think it’s exciting to see new open source projects like https://github.com/ory/kratos https://github.com/ory/kratos or https://github.com/supertokens/supertokens-core https://github.com/supertokens/supertokens-core that finally break up this misconception! These both have the same architecture as say an Auth0. Supertokens API provides a proprietary alternative to a constrained OpenID Connect protocol. Kratos has a companion project which exposes the server via OpenID Connect. The supertokens API may have been easier for _them_ to implement than all of the potential OAuth and OpenID Connect extensions, but when going with constrained profiles like the OpenID Connect Basic Client Profile it would be difficult to be substantially simpler without being less secure.