Which SAML 2.0 profile lets a client with no browser complete a federated login, and what does relying on it cost?

## Why this is the honest comparison point When people compare federation standards, they usually compare age or file format. The comparison that actually decides selections is narrower and more useful: **what does each standard require of the thing doing the logging in?** SAML 2.0's flagship profile answers that with a browser, and everything about it follows from that assumption. This is the part candidates almost never know, and it is where a selection either survives contact with the estate or does not. ## The two profiles, named exactly | Profile | Identifier | What the client must be able to do | |---|---|---| | Web Browser SSO | `urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser` | Be, or drive, a user agent that follows navigation and submits forms | | Enhanced Client or Proxy | `urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp` | Locate the identity provider itself and relay the exchange, carried in PAOS header blocks | **Web Browser SSO** is the profile behind essentially every SAML integration you have met. The user agent is not a bystander in it: it is the transport. It carries the request to the identity provider, it carries the answer back, and it is what makes the whole thing work without the two servers ever talking directly. **Enhanced Client or Proxy** exists precisely because that assumption fails. The name says what changes: the client is *enhanced* — it takes on the job the browser was doing. Rather than being pushed around by navigation, it knows where to send the request and how to hand the answer back, and the exchange rides in **PAOS** header blocks. A *proxy* in the profile's sense is an intermediary doing that on a plain client's behalf; note this is a proxying party inside the profile, not an HTTP forward proxy and not an access broker. ## What it costs, honestly Three costs, and they compound: 1. **Both ends must implement it.** A profile only works if the identity provider offers it and the service provider consumes it. ECP is not a client-side trick you can adopt unilaterally. 2. **Both ends must enable it.** Even where the software supports it, it is commonly left off, because the deployment was built for browsers. In a federation with many member organisations, you are asking each one to turn on a path they have never operated. 3. **You own client logic forever.** The client now contains federation code — finding the identity provider, relaying messages, handling failures — that in the browser profile lived in software you did not write. ## How to use this in a standard selection The usable form of this knowledge is a criterion, not a fact. Ask of the estate: *what kinds of client will need to log in over the next five years?* Then: - **All browser-based, all the time.** SAML 2.0's browser profile is a fine answer and the incumbent usually wins. - **A material population of native, desktop, command-line or single-page clients.** SAML 2.0 can serve them only through a profile both ends must adopt, whereas the token-era standard treats those clients as its mainstream case rather than an extension. That asymmetry, not elegance, is the selection argument. - **Mixed, with the mix changing.** This is the real answer in most estates, and it is why coexistence rather than replacement is usually the plan. A fourth option exists and should be named rather than assumed away: some estates still carry **WS-Federation Version 1.2**, an OASIS Standard published in May 2009. Treat it as a third distinct standard a member may arrive speaking. ## What this leaf deliberately does not decide Two boundaries keep this answer clean: - **Message mechanics are not here.** How a request is encoded onto a particular binding, what fields it carries and how a response is correlated belong to the material on the standard's own messages. Selecting a profile is a question about capability and adoption. - **Client-platform practice is not here either.** How a native application should host a login on a given operating system is its own subject with its own recommendations. What belongs in a selection review is the narrower claim: with SAML 2.0, a non-browser client needs a profile both parties support; with the token-era standard, it does not. A compact interview answer: *SAML 2.0's browser profile assumes a user agent, ECP is the standard's own answer when there is not one, and its cost is that it is opt-in at both ends — which is why non-browser clients are usually the argument that moves an estate.*