Why apps should not render identity provider web sites in-app

Nowadays there are several public identity providers (IdP) such as Google accounts, Facebook accounts, GitHub accounts or SwissId accounts, just to name a few.

More and more mobile apps are starting to accept one or more of these IdPs as a replacement or as an addition to app specific user accounts to authenticate their users.

A common protocol to accomplish this is the OAuth 2.0 / OpenId Connect 1.0 protocol. In simple terms, here is how this protocol works:

1. The app or web site, which needs to authenticate a user, provides a button/ link to the web site of the IdP and adds a redirect link to the request.
2. When the user clicks the button/ link, the web site of the IdP gets opened.
3. As the users know and trust the IdP, they will enter their user names and passwords on that site. The original app will never see their passwords.
4. On completion of the IdP process, (simplified) the IdP will send a token to the redirect link the original app/ web site passed as parameter to the authentication request link.
5. The app / web site can then use this token to e.g. check the rights (roles) of the user (authorization).

Now, unfortunately, there are several apps which open the IdP web sites (step 2) "in-app", using a web view like component to render the IdP web site directly inside their apps (mostly for user experience reasons, I guess, so the user doesn't have to leave their app).

While this technically works, there is now no way for the user at step 3 to tell if the request for authentication is genuine or if this is a phishing attack by the app. There is also no way for the user to tell, if a developer wanted to do something "clever", which accidentally compromises the sensitive password. It breaks the OAuth 2.0 / OpenId Connect 1.0 concept that the original app will never see the users' passwords.

It doesn't help that the rendered web site shows the correct name of the IdP and it doesn't help either to show the URL e.g. at the top the app, as this is what a phishing app would do, too, wouldn't it?

As long as the request for authentication is processed in the original app, the user cannot tell if the request is genuine.

So by trying to increase the user experience by using an in-app web view component, you take away any possibilty for the user to check who actually sees the entered password.

Bottom line:

Dear app developers: please, never use an in-app web view component for authentication requests to third party IdPs. Use the browser or the IdP app instead, so the user has a chance to check the genuineness of the request.


There are already many companies and organizations who try to sensibilize users how they can detect phishing attacks, and checking the URL in the browser is one of the most effective detection mechanisms.

So please don't dilute these campaigns by excluding options for the users to perform these checks.

I think especially apps from the big companies should set a good example here, which at the time of writing, unfortunately, is not always the case.

And I guess it also would be good if review processes (e.g. such as the one from Apple to accept an application for their app store) would check that these kind of authentication don't take place "in-app".