@high-optician-2097 I remember an article you made about using "in-app browser" to access the login flow instead of raw forms inside the native application (for more security). Just saw this today: https://twitter.com/KrauseFx/status/1560370732705742848?t=21z55jJr30CXgYVOVMNPlw&s=09 Any thought? Did you notice this in the past? (I guess a fake app could bring you to the official sign-in page (so the user is confident about being on the official login page), but the fake app would watch your inputs to steal your credentials even if the login flow won't work at the end) Thank you,

Seems like you can scratch “fake” since who knows what Instagram and TikTok are “monitoring”.

Do you mean this blogpost: https://www.ory.sh/oauth2-for-mobile-app-spa-browser/ ? Right at the top it says:

Before reading ahead, keep in mind that OAuth2 and OpenID Connect are delegation protocols. OpenID Connect is useful when you want to become a “Sign in with ...” provider like Google or Twitter. If you plan on allowing third party developers access your user’s data with their consent (e.g “Access to your private repositories”), OAuth2 is the correct choice. Using these two protocols in first-party scenario, for example OpenID Connect to attempt and solve “SSO”, can become quite complex due to several conceptual limitations.

If you are looking to solve authentication (login), sign up, profile management, and more check out the Add Authentication to your React Native App article.

So we actually recommend using the flows in Ory Kratos, which do not use a browser for mobile. But you can still implement a safe OAuth2 flow on mobile with PKCE, not sure if that is related to what you posted 😅

@magnificent-energy-493 oh ok! I'm using Hydra for more than 2 years (Kratos was not yet ready at that time), and I talked to the team that was explaining the benefits of having a login flow in a browser (to check SSL+officialDomain) to give the user some hints if that's a phishing app. The conclusion was they banned the "implicit" flow to be sure people would not implement this. I'm in my case using an in-app browser to perform the login flow. When you say Kratos is not, where the login form is displayed? About PKCE I understand it prevents to hijack a session since the client keeps a code. I was just mentioning in case of in-app browser: • bad guy could create a phishing app • this phishing app would launch the login flow (same flow as I do) with the real domain (so the brower shows right metadata) • the phishing app listens for inputs in this page (stealing credentials) • but indeed, since that's a fake app, the login flow could not be successful since the postLoginRedirectTo list should only allow specific deeplink sheme (like myapp://localhost/login/success), but still, credentials would be leaked Did I miss something? EDIT: looking more about it... it seems "native in-app browsers" are safe enough to prevent this? It's for specific in-app browsers. Then, if the "bad guy" is motivated... it's always possible to mimic an in-app browser (they still need to go through the app store reviews)... and in this case I guess nothing can be done ^^ (sorry for the post, was curious to know your thoughts and if you saw that in the past)

When you say Kratos is not, where the login form is displayed?

In your application 🙂 You can check out our reference application here: https://github.com/ory/kratos-selfservice-ui-react-native https://apps.apple.com/fj/app/ory-profile-app/id1536546333 https://play.google.com/store/apps/details?id=com.ory.kratos_self_service_ui_react_native this blogpost goes into the full details: https://www.ory.sh/login-react-native-authentication-example-api/ You are right PKCE does not really help with the malicious in app browser. .

I am not sure I get this, how could they switch out the in-app browser you have in your app (lets say you use the native safari on iOs) for their malicious browser?

I was referring to a phishing app, so let's say my app package name is "com.myapp.app", they would mimic the "home UI with login buttons" and publish it as "com.phishingapp.app" with same name on the store (or almost the same name) and try to promote the app. It was an argument in the past to switch over login in the browser on mobile (because since an app is fullscreen you don't know if it's the real one if you didn't pay attention in the store) But today I don't know if that's still something used?

Yea that makes sense in the context. I don’t know what would be the best practice today, but maybe @high-optician-2097 knows as the security OG 🙂

I wish I could answer but I have too many things on my plate right now, sorry 😞

Inappbrowser.com is a really helpful tool, thanks for sharing the link here! If you enter user credentials into the native UI of a mobile application, you pretty much give that application and its developer your password. A more trustworthy way is to have the app redirect to a browser that shows the login screen of the OIDC provider. When you enter your password into that browser, the mobile app cannot see you password and only receives the credentials it is supposed to get. Ideally, that's the stand-alone browser on your phone. These native browsers are pretty well protected against snooping by other apps. A less ideal option - but still much better than entering passwords into a native UI - is an in-app browser. The default in-app browsers are also pretty well protected against snooping. But nothing stops an app from creating a fake in-app browser that looks like a browser but does pretty much anything the app wants, from taking you to a fake website over displaying the wrong URL in the address bar to logging all your keystrokes. This problem isn't new. Finally we have a website that we can go to in an in-app browser to check whether that in-app browser does a few well known snooping attacks on you by injecting Javascript into the pages you visit. Always be careful where you enter your password. Make sure it's the native browser (through the "recent apps screen"), and the URL you are at is the correct one.