How does this compare with SimpleFIN: https://bridge.simplefin.org/info/developer
SimpleFIN seems simple and still secure. But maybe I'm missing something?
Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
101–110 of 186 posts
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#102> One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_i…
> That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server. All secrets go over the wire, which is protected with TLS. Ultimately the security is delegated to TLS. You're simply wrong here. > Count me as pretty dubious of letting some unknown group try to re-implement bank authentication witho…
You're correct that OAuth2 ultimately delegates all security to TLS--if that concerns you, you're better off using OAuth1a that has its own signing/verification protocol.
The statement in the OP that:
> the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request.
is incorrect as written. [In the case of a confidential client] The server does authenticate the client, and it does know who is making the request.
If you're going to claim that TLS-protected authentication somehow counts as "does not authenticate the client" then I guess you'll agree that Gmail "does not authenticate" my IMAP client when it makes a TLS-secured connection and sends my 'app password' over the wire.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#103Actually oAuth 1.0 is less secure than oAuth 2.0 because it engages in security theater. It doesn't even require https and as a result any man in the middle can eavesdrop on the requests. And if the token is leaked, it's game over.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#104One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log int…
[deleted]
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#105One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log int…
The flow we (Mondo) are considering for this: 1. MyLittleApp opens web view to log into Mondo 2. User enters something to identify themselves into the web view (eg. email address, phone number) 3. We dispatch a notification to the user's registered device (ie. the Mondo app where the user is logged in – this may be the same device or a different device) 4. User opens the Mondo app and accepts/rejects the authorisatio…
I have two factor auth configured on my most sensitive logins (Microsoft account, Google account, Lastpass), and it works almost exactly the same. Except I use a standard Authenticator app. No need for proprietary protocols or apps.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#106One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log int…
How exactly does one do this in iOS? There is a reason that Apple only allows Safari to power WebViews. How exactly would you extract the user's password from the DOM of the WebView on a non-jailbroken device using ANY APPLE APIs if the page was legitimately loaded from https://yourdomain.com ??
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#107At Qbix we developed a much more secure way than oAuth to instantly personalize a person's session -- and even connect the user to all their friends -- while maintaining privacy of the user and preventing tracking across domains by everyone except those they choose to tell "I am X on Y network" ... it also restores the social graph automatically on every network and tells you when your friends joined one of your networks.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#108One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log int…
This is why the OAuth Identity Providers that take security most seriously do not allow WebView login (or at least provide an SDK where you don't need it).
How exactly do you prevent a user agent WebView in an app from spoofing iOS Safari?
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#109In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/Z protocols, the author of this post does not truly understand OAuth 2, nor have they looked in any appropriate depth into supplements like OIDC or alternatives. 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 impl…
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 s…
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).
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.
Re: Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it
#1101. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a…
I disagree with your first point. The fundamental problem OAuth solves is secure authentication. OAuth 2.0 provides this at a bear minimum as it can be broken in any way SSL/TLS can be broken.
The argument the author is making is that this level of security is not sufficient for a bank. I think I agree with this statement.
For general use, OAuth 2 provides a sufficient level of security since the platforms that use it are usually only as secure as TLS, too.