Why can’t I use query Response Mode with id_token Response Type (“implicit” flow)?

Question

Although I think OpenID 2.0 is a cleaner and better authentication protocol than OpenID Connect, I have to implement an OpenID Connect IdP.

One point I like in OpenID 2.0 is that the IdP can return a signed identity to the Relying Party (through the user agent) and there’s no additional round-trip between the RP and the IdP.

At first sight, OpenID Connect defines an “Implicit” flow which looks fine to me. But when I look at the details, it seems to be designed only to be used with “Clients implemented in a browser using a scripting language”.

I thought that I might anyway use the “Implicit” flow with a server-side RP, using the “query” Response Mode, but the “OAuth 2.0 Multiple Response Type Encoding Practices“ document explicitly forbids the use of “query” Response Mode with the id_token response type…

Why is it forbidden ? And more generally, why is the “Implicit“ flow frowned at?

As I understand it, as long as the ID tokens are signed, and the RP use (and verify) nonces, the “Implicit” flow should be safe.

Answer 1

2020-12 UPDATE

There is an OAuth 2.1 draft to get rid of Implicit flow - short summary here. OAuth 2.1 brings together the latest OAuth 2 best practices.

TLDR; best to avoid Implicit flow if you can.

---

And more generally, why is the “Implicit“ flow frowned at?

Because the access token is exposed to the user agent (browser). See Implicit flow diagram in the OAuth 2 spec, then compare it to the Authorization Code flow that doesn't expose the token to the user agent.

... explicitly forbids the use of “query” Response Mode with the id_token response type... Why is it forbidden ?

Quick definition:

scheme://host:port/path?query#fragment

The "query" portion of a URL is easily inspected by many parties - it may be recorded by the user agent (e.g. browser history), and is often found in Web server request logs. Rule of thumb is to never send any sensitive information (e.g. tokens, authorization codes, passwords) via the "query" parameter.

However, the "fragment" portion is never sent in HTTP requests, nor will it appear in Referer headers. Only JavaScript executing on the user agent (browser) would have access to it.

For instance, a client (browser) could make a request like this:

GET /authorize?
  response_type=id_token%20token
  &client_id=s6BhdRkqt3
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
  &state=af0ifjsldkj HTTP/1.1
Host: server.example.com

Auth server would respond with (note the "fragment" denoted by "#"):

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj

The browser would then exclude the "fragment" when it redirects to the target location. JavaScript code in the browser is expected to submit the relevant token(s) using a more secure mechanism (e.g. POST body).

There are quirks among the various browsers, but nothing apparent that defeats the security assumption.