4 ms·

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scen

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which had a token from OAuth server 1, and it needed to exchange it for a token from OAuth server 2, and we needed some policies to decide whether that token exchange was allowed or not. And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. > Which ones are supported by the provider? You guessed it, it's all implementation-dependent. Security needs vary widely from system to system. So they defined a protocol which supports many different scenarios. But if your application only needs two of them, why implement the other N? OTOH, for someone who actually needs one of those other scenarios, having it standardised makes their life easier. You can’t expect the protocol to tell you which scenario you have, that’s inherently “implementation-dependent”, to the point that calling it that is getting tautologous

LukeShu 4y ago
> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecified by OAuth. How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): - OAuth: implementation defined - most implementations: use our library, which validates the token using undocumented logic - OIDC: there's a user-info endpoint you can call to, but lots of OAuth authorization servers don't fully implement OIDC, and even if they do, that's a lot of extra round trips - RFC7523: The token is a JWT, validate the signature and claims... but everyone issues RFC6750 "bearer" tokens, not RFC7523 "urn:ietf:params:oauth:grant-type:jwt-bearer" tokens. But if you just close your eyes and pretend that your 6750 opaque token is actually a 7523 JWT and parse+validate it as such, that'll work most of the time. So yeah, OAuth is hard because there's no great generic library, because a core part of it is implementation-defined, so you have to either do it yourself or use a specific implementation's library, and none of those libraries work quite the same. (In the above, and for 99% of folks, "OAuth" = RFC6749+RFC6750)
- rtpg 4y ago
  In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? > How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): At the beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site. This is not 100% perfect compared to "remote server has some signing" but it does allow purely local verification of tokens when they are first received, as you can stick stuff into the "state" request parameter (as anyone should be anyways to avoid trickery).
  - LukeShu 4y ago
    > In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon signature verification. It could be anything. > At the beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site. So you redirect the user's browser to the IDP, with the nonce in the URL. The user grabs that nonce from the URL bar, then manually navigates to your redirection-endpoint, putting that nonce and their own fabricated token in the URL.
    - krinchan 4y ago
      ...what? The server generates the auth code and redirects the user agent to your callback. You exchange that code with the IDP (over HTTPS which yeah that's its own nest of wormy trust) to get back a token. They can't inject a token because you don't get the token from them, just the one time code. If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS endpoint. Introspection is standardized and an RFC. The state param is just a fucking session identifier. All these URLs are defined and provided via the .well-known/openid-configuration endpoint. If your IDP publishes that endpoint correctly, most OAuth2 client libraries Just Work (TM) when pointed at the IDP domain. Do EITHER of you even use OAuth2 outside of just cargo culting something you found off GitHub?
cogman10 4y ago
> And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. That's because OAuth in the industry has been changed to only talk about authentication (AuthN) and not (or very lightly) authorization (AuthZ). And, for the better, AuthZ is so use-case specific that bundling it together with AuthN is just asking for trouble. Consider AWS and IAM permissions. How would you implement an IAM AuthZ policy system with OAuth? Would you actually want to? AuthN is a relatively simple process which is why that flow through OAuth (and specifically OIDC) is fairly well trodden and defined. The OAuth Authz capabilities are infrequently used which is why you see them being so spotty.
- evntdrvn 4y ago
  huh? OAuth is literally a "delegated authorization framework"
  - krinchan 4y ago
    It isn't. OAuth2 really did away with AuthZ and focused on AuthN, regardless of what anyone says. You have scopes but even those outside of the OIDC scopes are wishy washy and meaningless outside of each implementation.

LukeShu 4y ago

> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecified by OAuth. How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): - OAuth: implementation defined - most implementations: use our library, which validates the token using undocumented logic - OIDC: there's a user-info endpoint you can call to, but lots of OAuth authorization servers don't fully implement OIDC, and even if they do, that's a lot of extra round trips - RFC7523: The token is a JWT, validate the signature and claims... but everyone issues RFC6750 "bearer" tokens, not RFC7523 "urn:ietf:params:oauth:grant-type:jwt-bearer" tokens. But if you just close your eyes and pretend that your 6750 opaque token is actually a 7523 JWT and parse+validate it as such, that'll work most of the time. So yeah, OAuth is hard because there's no great generic library, because a core part of it is implementation-defined, so you have to either do it yourself or use a specific implementation's library, and none of those libraries work quite the same. (In the above, and for 99% of folks, "OAuth" = RFC6749+RFC6750)

rtpg 4y ago
In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? > How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): At the beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site. This is not 100% perfect compared to "remote server has some signing" but it does allow purely local verification of tokens when they are first received, as you can stick stuff into the "state" request parameter (as anyone should be anyways to avoid trickery).
- LukeShu 4y ago
  > In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon signature verification. It could be anything. > At the beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site. So you redirect the user's browser to the IDP, with the nonce in the URL. The user grabs that nonce from the URL bar, then manually navigates to your redirection-endpoint, putting that nonce and their own fabricated token in the URL.
  - krinchan 4y ago
    ...what? The server generates the auth code and redirects the user agent to your callback. You exchange that code with the IDP (over HTTPS which yeah that's its own nest of wormy trust) to get back a token. They can't inject a token because you don't get the token from them, just the one time code. If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS endpoint. Introspection is standardized and an RFC. The state param is just a fucking session identifier. All these URLs are defined and provided via the .well-known/openid-configuration endpoint. If your IDP publishes that endpoint correctly, most OAuth2 client libraries Just Work (TM) when pointed at the IDP domain. Do EITHER of you even use OAuth2 outside of just cargo culting something you found off GitHub?

cogman10 4y ago

> And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. That's because OAuth in the industry has been changed to only talk about authentication (AuthN) and not (or very lightly) authorization (AuthZ). And, for the better, AuthZ is so use-case specific that bundling it together with AuthN is just asking for trouble. Consider AWS and IAM permissions. How would you implement an IAM AuthZ policy system with OAuth? Would you actually want to? AuthN is a relatively simple process which is why that flow through OAuth (and specifically OIDC) is fairly well trodden and defined. The OAuth Authz capabilities are infrequently used which is why you see them being so spotty.

evntdrvn 4y ago
huh? OAuth is literally a "delegated authorization framework"
- krinchan 4y ago
  It isn't. OAuth2 really did away with AuthZ and focused on AuthN, regardless of what anyone says. You have scopes but even those outside of the OIDC scopes are wishy washy and meaningless outside of each implementation.