Search code examples
iosauthenticationauthorizationopenid-connectopenid

Login Native vs In app browser tab VS authenticate VS authorization + PKCE

I am confused about the different login methods and the impacts on the user experience. I would like to do native mobile app login on iOS, that means the user is not redirected toward the web page (or in app browser tab) to login. For example : All banking applications (Ex: N26) the login method is always the same : User enter his login / pwd and then he connects.

However, when I see the "Best practice login app for mobile" I can see they use authenticate + authorization code flow with PKCE. But using this method, my mobile app has to be redirected to the authorization server (Like when we want to connect with google).

So my questions are :

  1. Is is possible to do native login using authorization code flow with PKCE without opening an in app browser tab ?
  2. In terms of security, authorization code flow is better than native ? If yes, why all banking mobile applications are not using it ?
  3. if the authorization server is the same than the resources server, is it possible to not have this redirection for the login ?

For now, my server use OpenID, tomorrow maybe OpenIDConnect.

Thank you for your answer :D.

Solution

  • Context

    N26 as well as most banking apps do not support Single-Sign-On (SSO).

    Auth code flow + PKCE is a way of securely having your user login with SSO, usually using a well known Identity Provider (IdP) as Google. Then, assuming your selected IdP follows the OIDC specs, you will be able to receive an idToken which will represent the user who just logged in and some of her details (called token claims) like her email, name, etc.

    Answers

    1. Auth code flow + PKCE is related only when you use OIDC SSO, not with native login.
    2. In order to implement a native login you would have to be the "authority" who keeps the data required to authenticate users like email, password etc. Otherwise, Google (or any other IdP) is responsible for that. SSO provides better UX (as long as the redirect to the IdP is not poorly designed) and users prefer it since they are usually already logged in to their IdP, thus they do not have to remember and type credentials. However, the reason that lots of banks do not use SSO is that they do not trust Google. If Google gets compromised, the malicious party would be able to issue tokens that would allow them to impersonate anyone. Same for availability. If Google goes offline for some reason, users will not be able to login. I guess banks believe that they can provide better security and availability guarantees on their own.
    3. Again, you need the redirection only when using SSO OIDC. If you are not using that, and end up using a native login no redirection will be needed. That being said, it is a good practice too keep your authentication server separate to your back end.