131–140 of 186 posts
Earlier quoted context omitted.
Yes, but browsers design goal is to allow educated users to distinguish fake and legitimate sites (URL bar should never be forgeable). With mobile apps, the app can display anything and there is no way for even well educated user to recognize forgeries.
I think that's Android/iOS responsability.
One 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 describes the flow for a "trusted client", which is not the correct flow to use for securing this scenario. Instead, the "untrusted client" flow looks like this: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp registers itself with BankOfMars, which then has sole discretion over whether to allow it to access data hosted by BankOfMars. 5) If ap…
One 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 ??
http://www.priyaontech.com/2014/12/native-%E2%80%93-js-bridg...
One 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 describes the flow for a "trusted client", which is not the correct flow to use for securing this scenario. Instead, the "untrusted client" flow looks like this: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp registers itself with BankOfMars, which then has sole discretion over whether to allow it to access data hosted by BankOfMars. 5) If ap…
This is a problem with mobile apps unfortunately, since this type of browser interaction is going to be all over the place. For web apps it works just fine.
Earlier quoted context omitted.
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 attemptin…
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.
Earlier quoted context omitted.
many if not most people input the www subdomain by rote. unless teller does not care about that category of people, it should probably fix the issue
Of course they should. Redirect traffic from www.teller.io to teller.io
Earlier quoted context omitted.
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 attemptin…
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…
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.
https://github.com/TokenBinding/Internet-Drafts
http://www.browserauth.net/home
It's already implemented in Chrome.
Earlier quoted context omitted.
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…
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 ove…
In 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…
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.