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.

  • The implicit flow wasn’t designed for « browsers », but for network topologies where the IdP and relying party can’t directly communicate (hence using the user-agent as a middle-man). Any http-capable user-agent is viable in this flow.
    – korrigan
    Commented Mar 3, 2018 at 23:35

1 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:


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?
  &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#
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .