3 ms·

Depends. The core issue is that a lot of developers confuse authentication and authorization. And oauth kind of muddles the water on that front by vaguely doing

Depends. The core issue is that a lot of developers confuse authentication and authorization. And oauth kind of muddles the water on that front by vaguely doing both but not really. All it does really is exchange tokens (assertions). Anything JWT related is orthogonal to oauth. Oauth does not actually provide any semantics for the tokens you exchange. They might be JWTs and you might be able to verify them. Or they might just be some random number, a hash, or some kind of database id. But you would have to know in advance what it is exactly and what the proper process for verifying the token is. In the case of a random number or some kind of session id, the process of verifying that token would involve looking it up from some kind of database or via some kind of API. Alternatively, with a JWT, it might be a signed one (hopefully) and you'd be able to check the signature if you have the public key. All you have at this point is a blob that was signed by someone that you might or might not trust. The claims and other meta data in the token would tell you hopefully who the person is (authentication) and the level of access they might be given (authorization). The JWT spec defines some fields that you might use for that. But it's up to you to check all those things and verify them. The point is, that a lot of this stuff is simply implementation/vendor specific and you just need to know what to check and how and why. And it's on you to do all those things. This is not an issue with oauth, or JWTs, but with incompetent developers doing things wrong or being lazy/negligent/indifferent. Which sadly is very common. Lots of people that get busy implementing all sorts of stuff without any formal training. And a lot of this stuff isn't even taught properly in schools/universities. This falls in the same category as putting passwords plain text in a database, not setting up ssl certificates, running your database on an open port on the internet, and similar things that developers do wrong all the time. Because they don't even know the basics of how to do things right. A lot of these things would be caught during any half decent audit. And quite a few of those things could expose the companies involved to some expensive law suits. Which is why lots of companies spend money on audits because they don't like expensive law suits.

arka2147483647 3y ago
Nope. The thing about cryptography you always hear being said is "don't roll your own crypto", because you don't know all the complexities and failure modes that experts have researched. In o-auth, just you comment mentions multiple ways of doing things, and different responsibilities the developers have in different circumstances. Essentially the developer is forced roll some of their own auth. Compare that, for example, to say how you use TLS. You just use the standard libs bundled everywhere, and open connection, and the the system does all the validation for you. The complexity is there, but average developer is not expected to understand it. O-auth simply exposes too many details to the average developer, and too many options to use them differently, for it to ever be secure.
- robertlagrant 3y ago
  While what you say is true about OAuth2, this isn't what "don't roll your own crypto" refers to, I think. It's more like "don't start implementing crypto routines yourself".
- jillesvangurp 3y ago
  That's just the way oauth works. I agree it's a messy protocol. Classic design by committee stuff. Exactly what you get when mutually incompatible security product vendors try to create a standard that covers what all of them do. Unfortunately, there are no good alternatives that don't have this problem. Basically people use all sorts of commercial products in the hopes that it will act like magic security pixie dust. Most of them are super complicated to work with. Or expensive. Or both. There's just no way around the fact that you need to know what you are doing and how stuff sticks together.
withinboredom 3y ago
> incompetent developers doing things wrong or being lazy/negligent/indifferent. Which sadly is very common. I was code reviewing a dev who was implementing some auth and I mentioned they should log something for audit purposes. They said 'auditing isn't one of the requirements of this ticket' ... at which point, I knew it was time to leave. Like do you need someone to write a ticket to do your job? When people come ask "who logged in and deleted my org's content" ... you better have an answer. This is software engineering 201: logging. It's like an electrical engineer wiring a house not up to code and saying 'I don't care because the customer didn't ask for it to be up to code.'
- namtab00 3y ago
  I get what you're saying, but... Logging is not auditing, AFAIK. Also, and I may be very wrong based on the way that org prepared tasks, he may have been signaling scope creep... If it's not in the task, you don't do it. If you think it should be done, you backlog it...
  - AckRite 3y ago
    I agree with the comment above yours but also feel that this is... different style of work? Or attitude? Not sure how to name it but feels like I also brushed up against this numerous times. I assume that line of "what is scope creep and what is assumed to be in scope even if not written down" has to be blurry but I tend to judge people on which side they end up on, because I feel it correlates to indifference etc. Ultimately, it feels like a bad approach to work relationships - you actually have to do personal groundwork in your team to unblur the line to where you and your team agrees. And if that doesn't work out - leaving is a valid, if sad, option.
  - withinboredom 3y ago
    Not to be pedantic, but it's called an "Audit Log", usually. So, it is logging, though if you don't keep your logs forever, it is usually logged to a db or something (but that isn't necessary -- depends on the industry, privacy policy, etc.). > If it's not in the task, you don't do it. If you think it should be done, you backlog it... You shouldn't have to be told to do your job. One day, someone is going to ask why X wasn't done (when it clearly should have been, by all industry standards, and especially when it is exactly one line of code) and "I was just following orders" doesn't work in any court, including the ones that get you fired. When implementing auth, almost no PM is going to write down "mitigates timing attacks" as part of the acceptance criteria, but you do it anyway because it is the right way to do it.
caseysoftware 3y ago
While what you're saying applies to OAuth in general, there are a lot less variables in this situation. This was specifically "Sign in with.." so we know it was OpenID Connect which mandates signed JWTs for ID tokens. Those JWTs would have an issuer (the social provider) to determine their source and the client id (to determine the intended app) so those aren't in question here. Further, since these are ID tokens, they WOULD provide authentication information (technically identity info) and minimal authorization info.

arka2147483647 3y ago

Nope. The thing about cryptography you always hear being said is "don't roll your own crypto", because you don't know all the complexities and failure modes that experts have researched. In o-auth, just you comment mentions multiple ways of doing things, and different responsibilities the developers have in different circumstances. Essentially the developer is forced roll some of their own auth. Compare that, for example, to say how you use TLS. You just use the standard libs bundled everywhere, and open connection, and the the system does all the validation for you. The complexity is there, but average developer is not expected to understand it. O-auth simply exposes too many details to the average developer, and too many options to use them differently, for it to ever be secure.

robertlagrant 3y ago
While what you say is true about OAuth2, this isn't what "don't roll your own crypto" refers to, I think. It's more like "don't start implementing crypto routines yourself".
jillesvangurp 3y ago
That's just the way oauth works. I agree it's a messy protocol. Classic design by committee stuff. Exactly what you get when mutually incompatible security product vendors try to create a standard that covers what all of them do. Unfortunately, there are no good alternatives that don't have this problem. Basically people use all sorts of commercial products in the hopes that it will act like magic security pixie dust. Most of them are super complicated to work with. Or expensive. Or both. There's just no way around the fact that you need to know what you are doing and how stuff sticks together.

withinboredom 3y ago

> incompetent developers doing things wrong or being lazy/negligent/indifferent. Which sadly is very common. I was code reviewing a dev who was implementing some auth and I mentioned they should log something for audit purposes. They said 'auditing isn't one of the requirements of this ticket' ... at which point, I knew it was time to leave. Like do you need someone to write a ticket to do your job? When people come ask "who logged in and deleted my org's content" ... you better have an answer. This is software engineering 201: logging. It's like an electrical engineer wiring a house not up to code and saying 'I don't care because the customer didn't ask for it to be up to code.'

namtab00 3y ago
I get what you're saying, but... Logging is not auditing, AFAIK. Also, and I may be very wrong based on the way that org prepared tasks, he may have been signaling scope creep... If it's not in the task, you don't do it. If you think it should be done, you backlog it...
- AckRite 3y ago
  I agree with the comment above yours but also feel that this is... different style of work? Or attitude? Not sure how to name it but feels like I also brushed up against this numerous times. I assume that line of "what is scope creep and what is assumed to be in scope even if not written down" has to be blurry but I tend to judge people on which side they end up on, because I feel it correlates to indifference etc. Ultimately, it feels like a bad approach to work relationships - you actually have to do personal groundwork in your team to unblur the line to where you and your team agrees. And if that doesn't work out - leaving is a valid, if sad, option.
- withinboredom 3y ago
  Not to be pedantic, but it's called an "Audit Log", usually. So, it is logging, though if you don't keep your logs forever, it is usually logged to a db or something (but that isn't necessary -- depends on the industry, privacy policy, etc.). > If it's not in the task, you don't do it. If you think it should be done, you backlog it... You shouldn't have to be told to do your job. One day, someone is going to ask why X wasn't done (when it clearly should have been, by all industry standards, and especially when it is exactly one line of code) and "I was just following orders" doesn't work in any court, including the ones that get you fired. When implementing auth, almost no PM is going to write down "mitigates timing attacks" as part of the acceptance criteria, but you do it anyway because it is the right way to do it.

caseysoftware 3y ago

While what you're saying applies to OAuth in general, there are a lot less variables in this situation. This was specifically "Sign in with.." so we know it was OpenID Connect which mandates signed JWTs for ID tokens. Those JWTs would have an issuer (the social provider) to determine their source and the client id (to determine the intended app) so those aren't in question here. Further, since these are ID tokens, they WOULD provide authentication information (technically identity info) and minimal authorization info.