Hi,

Coming across this thread late. I’m the Author of the TAuth post.

> What I don't understand is that he's saying people disable TLS checks so he's 
> going to solve it with mutual TLS? 

It’s simple. Mutual TLS enables service providers to assert the peers are 
properly authenticated and enforce this as a policy. This won’t stop an 
incompetent developer disabling peer verification but it will stop that 
developer using the service if they do.

> The reason an OAuth 2.0 server does not authenticate _public_ clients is 
> because, by definition, a public client cannot keep its client secret 
> confidential and so client authentication is almost meaningless. <snip> but 
> they don't recognize that their insistence relies on the assumption that a 
> secret key embedded in a client application can be kept confidential.

This is incorrect. Modern mobile clients are capable of keeping a secret 
confidential, e.g. the Secure Enclave Processor on modern iOS devices and the 
Android analogues. The SEP can generate key material and use it to encrypt and 
sign arbitrary data. Key material is generated within the SEP and cannot be 
exfiltrated. To me this is the definition of being able to protect its own 
secrets. The TAuth bearer token analogue is not sensitive at all and cannot be 
used without the corresponding key material.

> Does adding TOKBIND resolve the issues?

Feel free to correct me here. I wasn’t that familiar with token binding but 
after reading the draft IMO it’s inferior to TAuth because it binds tokens to 
the connection. This necessitates refresh tokens, which I find an impediment to 
developer experience. TAuth binds tokens to the identity (the cert and pkey) 
thus can be reused again and again across TLS sessions. Token binding also 
provides no cryptographic guarantees that the peers are verified and that the 
connection is private.

Best

Stevie Graham

Teller - https://teller.io/ <https://teller.io/>

@stevegraham
@tellerapi

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to