3 ms·

The chief problem with OAuth2 is that you can do almost anything and call it "OAuth2" -- the spec is ridiculously flexible, and allows all kinds of options that

by jtheory 14y ago

The chief problem with OAuth2 is that you can do almost anything and call it "OAuth2" -- the spec is ridiculously flexible, and allows all kinds of options that are explicitly stated within the spec as not advised. I'm fairly sure most of the flexibility is there to help migrating enterprise and legacy apps to OAuth2. It's not a great approach, though -- enough security disasters and the problems of migrating will simply go away, because the poor rep of the mechanism will mean no migrations are happening. I'm using OAuth2 for an API, but a small subset of it that doesn't seem to permit the abuse Egor covers -- though I'm going over it with a fine-toothed comb now. XSS vulnerabilities are more subtle than most other hacks, and so the dangers aren't as obvious in a simple review.

homakov 14y ago
but root of insecureness is OAuth2 spec, why would someone implement response_type as a parameter? Aha, spec says so! Why would anyone set redirect_uri dynamic, not static? Spec allows! Scope as a parameter, not a setting? Hi, spec!
- jtheory 14y ago
  Implementing the spec, you pick & choose. I don't support alternative response_types; I don't support dynamic redirect_uri (at the moment, it's completely static; in future we may offer the list option), and the allowed scope for a given client is set during setup -- you can't then request a scope you aren't authorized for, given your client id. I'm not breaking the spec -- it offers all of these paths as options. You don't have to implement all of the possibilities the spec covers. The bad thing about the spec is that some of the possible paths are indeed less secure (it even says so in the spec in places...), so the security of your OAuth2 implementation is purely up to your judgement. The nice thing about good specs is that you benefit from the presumably-better judgement of the folks designing the spec....

by jtheory 14y ago

homakov 14y ago

but root of insecureness is OAuth2 spec, why would someone implement response_type as a parameter? Aha, spec says so! Why would anyone set redirect_uri dynamic, not static? Spec allows! Scope as a parameter, not a setting? Hi, spec!

jtheory 14y ago
Implementing the spec, you pick & choose. I don't support alternative response_types; I don't support dynamic redirect_uri (at the moment, it's completely static; in future we may offer the list option), and the allowed scope for a given client is set during setup -- you can't then request a scope you aren't authorized for, given your client id. I'm not breaking the spec -- it offers all of these paths as options. You don't have to implement all of the possibilities the spec covers. The bad thing about the spec is that some of the possible paths are indeed less secure (it even says so in the spec in places...), so the security of your OAuth2 implementation is purely up to your judgement. The nice thing about good specs is that you benefit from the presumably-better judgement of the folks designing the spec....