I cringe every time I am prompted with OAuth in an app because of the lack of ability to verify that the page is actually originating from the represented source.

Are most app OAuth implementations exposing vulnerability because of obscured URL/origin?

Below are OSX and iOS apps... a web view (embedded web browser viewport without address bar) is created and the OAuth page is displayed without URL or SSL certificate - which could be easily spoofed and exploited with phishing techniques. The risk seems huge.

Cobook App on OSX

enter image description here

Trello App on iOS

enter image description here

  • 1
    Indeed this seems like a huge risk. And even if the address was shown, how many non tech savy users would notice a scam?
    – cen
    Sep 15, 2013 at 11:38

1 Answer 1


This does not violate the security section of the OAuth 2.0 RFC. However, the OAuth 2.0 threat model RFC mentions phishing. The issue of obscuring the origin of the authentication page is not listed... anywhere. As in, I have never herd of this problem and I don't believe it is documented.

One could make the argument that all authentication pages must always show their origin and show that they are protected with HTTPS. (Is your screen shot of an HTTPS page? There is no way to tell.) This is a medium/low risk vulnerability, and I think twitter should fix it. I recommend emailing security@twitter.com, twitter takes security very seriously and they have a great security team.

  • I just added another example and clarified some language. The problem within apps is that the authentication webpage is not displayed in a first-class web browser... just in an embedded web viewport within the application - no address bar, protocol, or non-spoofable way to indicate if it is HTTPS.
    – Luke
    Sep 15, 2013 at 2:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.