5 ms·

Somehow OAuth for native apps is never covered in “complete” guides, and yet it is among the most challenging (how do you verify an inherently untrustworthy cli

• throwaway894345 5y ago
  Why is meant by “an untrustworthy client”? I always assumed clients are inherently untrustworthy? I assume I’m misunderstanding your sense of “untrustworthy”.
  • hirsin 5y ago
    Clients are either public or confidential. Confidential clients have a registered credential (cert, secret) that's used to prove that eg your server backend is actually your server backend.
  • billti 5y ago
    The OAuth terminology can be confusing, and many write-ups assume you already know some of it, which doesn’t help. In OAuth, an “app” is considered a “client”, even if it’s running in a web server in a data center, as it’s a “client” of the other services involved (e.g. the authentication services and the resources/APIs it will access on behalf of the user). Now if it is running in a web server in a data center, it can be considered “confidential”, as the code/config is not readily available to attackers. Thus the app can hold things like private keys etc. without too much risk. On the other hand, if the “client” is an app you can install on a PC/mobile device or load into your browser (e.g. a “SPA” app), then this is a “public client”, as attackers can easily access the code and examine it for stored credentials, etc. Hopefully that makes sense.
  • goblin89 5y ago
    In server-to-server, the client is considered trustworthy—no third party is supposed to be able to get the source or inspect memory, and OAuth secret can be a thing. But if you are, say, GitHub, how can you prove that GitHub Desktop instance trying to auth on behalf of the user is genuinely GitHub Desktop and not some malicious impostor, who previously extracted all the tokens from the original app and now is trying to get access to user’s repos?
    • dwaite 5y ago
      How do you know that the Github desktop instance hasn't been compromised by eval()'ing some third party code, and is using the tokens the client already has? For that matter - what is the difference between a token in a piece of code on the desktop and code on a server to third-party attackers, other than the server is a much more attractive central location to attack so that you compromise everyone at once? A lot of effort is spent on trying to identify a client as trustworthy and in preventing exfiltration of tokens, but generally a good portion of the security budget should instead be spent on how to mitigate risks. A trusted system is one where you have accepted you are fubar if it is compromised. It is equally important to evaluate the trustworthiness of systems as it is to reduce the need to have trustworthy systems in the first place. That unfortunately means actually having security considerations as part of the overall system design, and not just firewalling systems with policy at the end. You can reduce overall risk at authorization servers by not supporting dynamic registration, or limiting such registrations to a small set of acceptable scopes and claims. You also want to make sure you can revoke compromised tokens in a reasonable amount of time, such as due to device compromise, client compromise (or identified malicious client), or user account compromise. That usually can be done with just refresh tokens with appropriately short lifetimes for many systems. But the underlying protected resources still need to be designed to reduce risk as well. They should not expose functionality which clients do not need, both by having limited scopes and simply not exposing functionality publicly via API at all. They should also minimize destructive actions - actions should be reversible, such as restoring a deleted record or cancelling a pending order. Additionally, you'll want to invest in phishing-resistant authentication as much as possible. That means sticking to best practices and going to an external agent (browser) when authenticating, and ideally adopting something like WebAuthn or mutual TLS or Kerberos. Determining trustworthy clients or limiting API access does no good if the user hands a malicious piece of software their actual system credentials.
• mooreds 5y ago
  Thanks for the feedback! I've had on my list writing a "mobile guide to OAuth" as well, because there's a lot to unpack there. I attended this session at Identiverse 2021: https://identiverse.com/idv2021/session/SESBSMQ1FA07QHXBG/ https://identiverse.com/idv2021/session/SESBSMQ1FA07QHXBG/ I don't think the video was online, but as I recall his advice was: * figure out your risk posture * secure your bearer token if you are using it * if you need higher levels of assurance, then use DPOP https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04 The other thing to consider is whether you are first party or third party. If you are really using third party auth, then you should follow RFC 8252 as linked above and pop out to the system browser. Otherwise you may use a webview (because if you control both ends, the tradeoff in improved UI may be worth the increased risk). Definitely agree on reading the specs. If you are interested in OAuth in general, it's worth reviewing the OAuth 2.1 doc, which is a work in progress but will consolidate a lot of best practices: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/