6 ms·

Author here: > For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a

Author here: > For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few implementation details (such as how to obtain user info, how to validate an Access Token), which the author seems to just assume are part of the spec, as he does with bearer token. Other parts, like the client/user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec. Last time I checked other access token types were still drafts and bearer tokens were the only stable kind. > Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder. I as a bank cannot attribute liability for an erroneous transaction to a developer if with both share the secret with which a signature is computed. If I as a bank am compromised and want to cover my arse by moving the blame to a poor external developer I can do that with a shared secret by forging signatures after the fact. This is precisely why I don't want shared secrets. Even if your point is valid re DH, why push that up to the application level and reinvent the wheel when you can get the same benefits, less intrusively by using a battle tested protocol circa 20 years old? > sigh. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only. This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? Finally, despite everything you say no OAuth 2.0 based protocol can guarantee privacy. People like that privacy when it comes to their finances I find. Sorry for any typos, I'm on the move. Thanks for your comments :)

parsnips 10y ago
>This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? For which developers?
- sjtgraham 10y ago
  The ones I spoke with when doing user research.
  - dlmetcalf 10y ago
    IMO, if they consider that too complex to handle, then application security is too complex for them to be working on too. I wouldn't want a developer who doesn't even know how to handle pipes, to go anywhere NEAR apps needing secure implementations.
Freak_NL 10y ago
> This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? If you are a developer tasked with working with web security related techniques, I would expect being able to use Bash, Curl, and anything needed to string together a couple of HTTP requests on the command line before your first cup of coffee of the day to be the least requirement of their skill set.
- andrewstuart2 10y ago
  Additionally, the kind of developer who uses cURL is not, in my experience, the kind to shy away from using bash pipes or writing a quick bash alias or function to streamline that process if they have to do it more than a few times.
andrewstuart2 10y ago
My DH comment was a bit aside the point I probably should have made. (Also, apologies for my sarcasm re: bash pipes -- that was unnecessary and probably unproductive). > Public key cryptography can be used with JWT tokens but they don't solve the problem of how the client will generate key pairs, demonstrate proof of possession of the private key, and enrol the public key with the API. JWT is not in any way attempting to solve the problem of client identity and authentication. Rather, the question of federated user identity and how to validate that the identity assertion came from a trusted source (where the PKI and assertion signing comes in). Furthermore it is signed with, among other assertions, the audience assertion so that you can cryptographically verify that a token was given with the authorization of a user by a trusted service (your JWT provider, via whatever authN methods it allows) and to a given client. This should give a substantial enough audit trail to enable reasonable proof that an end-user authorized a client (which itself had to authenticate to the provider) to perform an API transaction if it can be proven that the signature was validated and that the token issuer was clear about exactly what the user was giving the client authorization to do. OAuth2, OIDC, and all modern standards I'm aware of also require client validation of some form. From the OAuth2 spec: Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair). This implementation is unspecified in OAuth2 but could (and in your case probably should) certainly include digitally signing each API request (much like twitter and amazon require) with a private key and validating the signature against the client's registered public keys as well as the constraints (especially audience, scope, and expiration) given via the token. If your goal is to provide a non-repudiable audit trail of user identity and authorization and client identity and agency (authorized by the user to perform X) then OIDC, JWT, and client AuthN via request signing with registered keys should be more than sufficient to avoid liability in the case of rogue clients or shady users. As always, the audit trail is the most important piece, along with sound crypto and standard practices that have been audited by appropriate experts, so that your audit evidence cannot be reasonably called into question.
- uncleyo 10y ago
  I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done? You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you identify the client but not sure you can ever identify app developer with it (if needed for audit purposes). Or am I missing something, maybe?
EGreg 10y ago
If we can get an app for banking, I wonder if we can ever get an app for voting. A vote would seem to be less valuable than access to an enormous sum of money, yet one is available to be instantly and the other requires standing in line.
- e12e 10y ago
  The difficulty is not secure voting, the difficulty is a secure, secret vote. So that the person that cast the vote, can't prove which way they voted ("Hey, see, I voted for you, now pay me the 10.000 USD you promised me"), that other's cant prove which way any given person voted (or indeed, prove that the vote wasn't blank) ("Put him on a black-list, he voted for $wrong candidate!"). As far as I know, secure on-line voting is still an open research question (and that's just the theoretical bit, never mind building a real, concrete system).
- dlmetcalf 10y ago
  Nope. If you control the votes, you control the money, the laws that make it, the military (including intel services, alliances & secret police), plus the rest. You don't even need to buy a presidency then. Once you control votes, you can privilege escalate to do almost anything. There's probably nothing else we should be as truly concerned about securing properly. It's already been rigged and EXTREMELY probable it was exploited for George W. Bush's election too. Electoral security is an absolute joke and a travesty. https://en.wikipedia.org/wiki/United_States_presidential_election,_2004#Points_of_controversy https://en.wikipedia.org/wiki/United_States_presidential_ele... https://en.wikipedia.org/wiki/Premier_Election_Solutions#Controversy https://en.wikipedia.org/wiki/Premier_Election_Solutions#Con...
andrewstuart2 10y ago
> Finally, despite everything you say no OAuth 2.0 based protocol can guarantee privacy. People like that privacy when it comes to their finances I find. What makes you say that OAuth 2 cannot guarantee privacy? I think you must have a very different definition of privacy than I'm used to if you can make this claim.
- blazespin 10y ago
  the premise is that mitm attacks are easy.

parsnips 10y ago

>This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? For which developers?

sjtgraham 10y ago
The ones I spoke with when doing user research.
- dlmetcalf 10y ago
  IMO, if they consider that too complex to handle, then application security is too complex for them to be working on too. I wouldn't want a developer who doesn't even know how to handle pipes, to go anywhere NEAR apps needing secure implementations.

Freak_NL 10y ago

> This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? If you are a developer tasked with working with web security related techniques, I would expect being able to use Bash, Curl, and anything needed to string together a couple of HTTP requests on the command line before your first cup of coffee of the day to be the least requirement of their skill set.

andrewstuart2 10y ago
Additionally, the kind of developer who uses cURL is not, in my experience, the kind to shy away from using bash pipes or writing a quick bash alias or function to streamline that process if they have to do it more than a few times.

andrewstuart2 10y ago

My DH comment was a bit aside the point I probably should have made. (Also, apologies for my sarcasm re: bash pipes -- that was unnecessary and probably unproductive). > Public key cryptography can be used with JWT tokens but they don't solve the problem of how the client will generate key pairs, demonstrate proof of possession of the private key, and enrol the public key with the API. JWT is not in any way attempting to solve the problem of client identity and authentication. Rather, the question of federated user identity and how to validate that the identity assertion came from a trusted source (where the PKI and assertion signing comes in). Furthermore it is signed with, among other assertions, the audience assertion so that you can cryptographically verify that a token was given with the authorization of a user by a trusted service (your JWT provider, via whatever authN methods it allows) and to a given client. This should give a substantial enough audit trail to enable reasonable proof that an end-user authorized a client (which itself had to authenticate to the provider) to perform an API transaction if it can be proven that the signature was validated and that the token issuer was clear about exactly what the user was giving the client authorization to do. OAuth2, OIDC, and all modern standards I'm aware of also require client validation of some form. From the OAuth2 spec: Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair). This implementation is unspecified in OAuth2 but could (and in your case probably should) certainly include digitally signing each API request (much like twitter and amazon require) with a private key and validating the signature against the client's registered public keys as well as the constraints (especially audience, scope, and expiration) given via the token. If your goal is to provide a non-repudiable audit trail of user identity and authorization and client identity and agency (authorized by the user to perform X) then OIDC, JWT, and client AuthN via request signing with registered keys should be more than sufficient to avoid liability in the case of rogue clients or shady users. As always, the audit trail is the most important piece, along with sound crypto and standard practices that have been audited by appropriate experts, so that your audit evidence cannot be reasonably called into question.

uncleyo 10y ago
I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done? You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you identify the client but not sure you can ever identify app developer with it (if needed for audit purposes). Or am I missing something, maybe?

EGreg 10y ago

If we can get an app for banking, I wonder if we can ever get an app for voting. A vote would seem to be less valuable than access to an enormous sum of money, yet one is available to be instantly and the other requires standing in line.

e12e 10y ago
The difficulty is not secure voting, the difficulty is a secure, secret vote. So that the person that cast the vote, can't prove which way they voted ("Hey, see, I voted for you, now pay me the 10.000 USD you promised me"), that other's cant prove which way any given person voted (or indeed, prove that the vote wasn't blank) ("Put him on a black-list, he voted for $wrong candidate!"). As far as I know, secure on-line voting is still an open research question (and that's just the theoretical bit, never mind building a real, concrete system).
dlmetcalf 10y ago
Nope. If you control the votes, you control the money, the laws that make it, the military (including intel services, alliances & secret police), plus the rest. You don't even need to buy a presidency then. Once you control votes, you can privilege escalate to do almost anything. There's probably nothing else we should be as truly concerned about securing properly. It's already been rigged and EXTREMELY probable it was exploited for George W. Bush's election too. Electoral security is an absolute joke and a travesty. https://en.wikipedia.org/wiki/United_States_presidential_election,_2004#Points_of_controversy https://en.wikipedia.org/wiki/United_States_presidential_ele... https://en.wikipedia.org/wiki/Premier_Election_Solutions#Controversy https://en.wikipedia.org/wiki/Premier_Election_Solutions#Con...

andrewstuart2 10y ago

> Finally, despite everything you say no OAuth 2.0 based protocol can guarantee privacy. People like that privacy when it comes to their finances I find. What makes you say that OAuth 2 cannot guarantee privacy? I think you must have a very different definition of privacy than I'm used to if you can make this claim.

blazespin 10y ago
the premise is that mitm attacks are easy.