Why does RFC 8252 have a native mobile app open its OAuth 2.0 authorization request in the device's browser rather than an embedded web view?
answer
- who else can see the keystrokes
- whose process the login page runs in
- its own cookie store, so no reuse
- no address bar, nothing to verify
- external user-agent or in-app browser tab
basics
~20 sRFC 8252 keeps the authorization request in an external user-agent because an embedded web view runs inside the application: the application can observe what is typed into it, including the resource owner's credentials, and it shares no signed-in session with the browser.
solid answer
~50 sRFC 8252 splits user-agents into two kinds. An **embedded** one — a web view the application creates — renders the authorization server's login page inside the application's own process, so the application can read the page, inject script and capture keystrokes. That defeats the premise of delegated authorization, which is that the client never handles the resource owner's password. It also has its own cookie store, so any existing sign-in at the authorization server is invisible to it and the user is challenged again. And the user has no address bar to check, so a fake login screen is indistinguishable from a real one. An **external** user-agent — the device's browser, or an in-app browser tab, which is browser UI shown inside the app but driven by the browser — removes all three, because the application cannot see inside it.
go deeper
Remember the one-liner: the login page must not run inside the app, because the app could read what is typed there and the browser's existing session would not be reused.
Explain the three consequences separately — credential exposure, a separate cookie store that kills single sign-on, and no address bar to verify — and place the in-app browser tab correctly on the external side of the line.
Show that you know the rule is not server-enforceable: the authorization server can only be recommended to detect and block embedded agents, so this is a client-side discipline you have to review for, and it is what creates the redirect problem the platform forms solve.
The angle is the trade-off you accept by pushing every native client onto the browser — a visible context switch on some platforms, a dependency on the platform's browser behaviour, and a support burden when a device's default browser misbehaves.
## The two kinds of user-agent RFC 8252 is a best current practice for running OAuth 2.0 from a **native application** — code installed on a user's device rather than served to a browser. Its first decision is not about the `redirect_uri` at all; it is about *where the authorization request is rendered*. - An **embedded user-agent** is a web view the application itself creates and hosts. The login page of the **authorization server** is drawn inside the application's process, under the application's control. - An **external user-agent** is a browser the application does not control. That includes a full switch to the device's browser, and it includes an **in-app browser tab** — browser chrome presented inside the application's screen but run by the browser, with the browser's own storage and its own address bar. The specification rules the embedded user-agent out for authorization requests. The reason is not aesthetic. ## What the embedded form takes away 1. **The credential stops being private.** OAuth 2.0 exists so that a client can act on one slice of a resource owner's account *without ever seeing the password*. A web view hands the hosting application the page's content, the ability to run script in it and the ability to watch input. Whatever the resource owner types at the authorization server is typed into a surface the client owns. The delegation has been undone by the container. 2. **Single sign-on stops working.** A web view has its own cookie store. A resource owner already signed in with the browser is a stranger to it, so the authorization server challenges them again — and the session it then creates is thrown away with the view. Users read this as "this app makes me log in every single time". 3. **The user cannot check who they are talking to.** There is no address bar and no TLS indicator, so a login screen the application drew itself looks exactly like the authorization server's. ## The comparison a candidate should be able to draw | | Embedded web view | In-app browser tab | Full browser switch | |---|---|---|---| | Runs in the app's process | yes | no | no | | App can read what is typed | yes | no | no | | Shares the browser's session | no | yes | yes | | Address bar visible to the user | no | yes | yes | | Acceptable under RFC 8252 | no | yes | yes | The middle column matters: the in-app browser tab exists precisely so that "use the browser" does not have to mean "throw the user out of the app". It is an external user-agent for the purposes of the rule, because the boundary the rule cares about is *whose process the page runs in*, not *which screen it appears on*. ## What this leaves for the redirect Once the request is rendered somewhere the application cannot see, a new problem appears that a web client never has: the authorization response is a redirect, and it has to cross back from the browser into the application. That is the work the three RFC 8252 redirect forms — a private-use URI scheme, a claimed `https` URI, and a loopback address — exist to do. Choosing the external user-agent is what creates the need for them. ## What the authorization server can do The client side of this rule is not enforceable by the server, because a web view can be made to look like anything. RFC 8252 therefore adds advice in the other direction: an authorization server **should** take steps to detect authorization requests arriving from embedded user-agents that are not its own, and block them. In practice that detection is heuristic and incomplete — it is a recommendation, not a guarantee, and it is why the rule is still written at the client. ## The failure this actually shows up as Two reports, both common. The first is a usability complaint: "I'm signed in on the web, why does the app ask again?" — an embedded view with its own cookie store. The second is a review finding: a screenshot of a login form rendered inside an application, with no address bar, asking for the credentials of an account the application has no business holding. Both have the same one-line fix, and it is a fix about the container rather than about the flow.
- What makes an in-app browser tab acceptable when a web view is not?It is rendered by the browser, not by the application: the application cannot read the page or the input, the user still sees the address and TLS state, and it uses the browser's cookie store, so an existing sign-in at the authorization server is reused. Only the framing is inside the app.
- Can an authorization server stop a client that ignores this and embeds a web view anyway?Not reliably. RFC 8252 recommends that authorization servers take steps to detect and block authorization requests made through embedded user-agents that are not their own, but the signals available are heuristic and a determined client can imitate a browser. The rule is written at the client because that is where it can actually be kept.
- Does this rule apply to an application's own first-party login screen?The specification's concern is third-party authorization, where the client must not see the credential. A first-party application authenticating its own users against its own authorization server does not have that separation to protect — but it still loses single sign-on and the address bar, so the same container argument usually wins anyway.
You would type your card's PIN into the bank's own terminal, not into a keypad the shop wired up itself and held out to you — however much you like the shop.
saying these in an interview costs you the question
- Says an embedded web view is fine because the app is trusted.
- Claims the app cannot read a remote page loaded in its own web view.
- Thinks the objection to web views is cosmetic or about branding.
- Believes an in-app browser tab is just a renamed embedded web view.
- Says single sign-on still works because a web view shares the browser's cookies.