Hacker News Reader

> 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.

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.

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.

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?

I think for that you'd probably need even more robust client authentication, like allowing clients to give you a CSR for their own CA, which can sign CSRs generated by each app installation and the chain can be traced from individual app, through the developer's CA, back to a trusted internal root certificate.

That lets developers maintain key confidentiality (devs keep their CA private keys) and maintain control over the app installations' access to signed certs (as well as cert lifetime).

Even if it's not a CA, OIDC has some brief words on signing JWT with a registered keypair, which gives a similar, though less robust, ability to keep the private key secret.

No matter what, any of these scenarios still involves figuring out a way to trust the installed app is authorized by the resource owner and the client developer to obtain a signed cert/token (thus shifting real financial liability onto them in OP's scenario). Which probably means requiring the end user to register for your service also, validating the user again rather than the app.

The fundamental fact remains that the human mind remains the only truly secret place, which is why passwords aren't going anywhere, and why DRM solutions have to rely on making it illegal to attempt to obtain the decryption key embedded in device, or making attempted recovery involve physical destruction of the key.

Yeah, thinking about the same. But then I saw the OP mentioned somewhere in the comments below that he's only thinking about server to server scenario (2LO/client credentials), so its those comments above discussing fake login UIs confused me that it was about 3-legged flow.

I had the same questions, and it's very hard to find the answer - took me a very long time to piece this together but this is how Google does it:

1) You create a "normal" client in Google Developer console (i.e. a web client) 2) You create a native/Android client in the same project. This client is shared across all phones. 3) You add a scope of audience:server:client_id:$NORMAL_CLIENT_ID to auth requests from the mobile. 4) You get back token minted for the web client, from the native client!

This is how it works:

https://developers.google.com/identity/protocols/CrossClient...

The reason it is safe is because you can only do the cross client stuff from a mobile client, which disallows any redirect urls except for localhost and a couple of other special URIS (see https://developers.google.com/identity/protocols/OAuth2Insta...)

It's ok that the secret is not really secret because it's not possible to use it to making a Phishing site since the redirect URL is localhost.

I guess that doesn't answer your "how does it identity the app developer" but it does tell you how these things are deployed at least, and the important fact that there's just one client (not one for every device)

I understand that. Problem is that I can "steal" other dev's app client_id and use in my app. So it seems impossible to use such client_id for auditing/evidence. With a web client I cannot do that since I don't own the domain, so I can be proven to be a party in some transaction

They should allow for push notifications. That'd be more secure

At the end of the day though, everyone has to sign their apps with certs that are pretty well validated. So, it really cuts down on funny business like you mention.

The official recommendations for native apps are here: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01

They suggest using PKCE (challenge-repsonse) https://tools.ietf.org/html/rfc7636 to authenticate clients that can't be trusted with a client secret.

the problem with this is you're rewriting client ssl, which isn't a very good idea considering how battle tested and hardened it is. how do you know you've dealt with all the edge cases that tls spec writers have been wringing their hands over for like forever. why do a one off impl of client auth inside the oauth protocol? why not use extremely well baked pre-existing infrastructure like webcrypto? it's not like you're magically going to be compatible with everything just because you follow the overly vague guidelines of oauth2. all you get kudos for is reading the spec - but how does that help your users?

security is a very hard problem, especially asymetric crypto security. rolling your own is generally not advised.

If there is a way to define and use client tls according to the current spec, that would be best. if not, I agree that it's probably a good idea to create a new spec

I agree though that the curlness of the spec is orthogonal to the discussion.

I don't think you read the piece?

- I am not reinventing TLS - This has nothing to do with OAuth - It uses WebCrypto for key gen and CSR signing

I was replying to stuart, not to you. He was trying to re-invent tls.

> 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.

the premise is that mitm attacks are easy.

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

For which developers?

The ones I spoke with when doing user research.

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.

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.

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).

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_ele...

https://en.wikipedia.org/wiki/Premier_Election_Solutions#Con...