OpenIdConnect: Is there an advantage to using code flow over implicit flow with form_post?

Question

Background: a traditional webapp with a server backend and 3rd party sign in. For this we get a validated id_token on our backend from the 3rd party, use that to identify an account in our system, and issue our own session cookie. We don't need access or refresh tokens from the 3rd party, and the front end doesn't need to see the id_token.

We are adding a new identity provider (Apple), and we have the option of using either:

1. Authorization code flow (without PKCE) & token exchange on backend using client secret
2. Implicit flow with response_mode=form_post, no token exchange, and we validate the id_token & nonce

The implicit flow seems as secure & more straightforward. Is there any reason I should use the code flow instead?

Note: Apple does not support PKCE. They also don't support the implicit flow, just the code & hybrid flows. Thus we would be using the hybrid flow here but ignoring the code, so treating it as if it's an implicit flow. Sorry, it's confusing.

---

Example

GET /authorize
  ?response_type=code id_token
  &response_mode=form_post
  &redirect_uri=my_url
  &state=the_state
  &nonce=the_nonce
  &scope=...
  &client_id=...

The callback sends the token directly to my backend

POST my_url
  ?id_token=the_token
  &code=ignored_code
  &state=the_state     

---

Additional information

Most recommendations I've found seem to recommend the authorization code flow with PKCE as being the most secure option because it keeps the tokens out of the url & browser history. However my understanding is that form_post also accomplishes that in a simpler way (assuming that you have a backend to process the request & use a nonce). Furthermore, I suspect because form_post is not universally applicable like code flow + pkce, that it is not discussed much, aside from these links I found:

• Auth0 suggests using implicit + form_post flow is a good option

This way you can have an optimized authentication flow (no need to exchange the code for an ID Token)

• Mention of form post being simpler from openid foundation:

To aid the implementation of the best practice, we recommend that OPs consider supporting OAuth 2.0 Form Post Response Mode, as it makes it simpler for clients doing code id_token to get both the code and the ID Token on the backend for verification.

• In this draft document about OAuth security topics, using form_post is suggested a few times as a mitigation for some attacks. But in general it strongly recommends code flow with PKCE.
• But if PKCE is not available, it doesn't mention what the next best thing is..
• Specification for form post response mode

Answer 1

I don't see any security advantage of using the authorization code flow in your case (traditional web application). Indeed, form_post is not vulnerable to referrer leaking or browser history leaking. Posting tokens is nothing new, it's how SAML2, the predecessor of OpenID Connect, worked well without bringing in any specific security weaknesses.

And form_post indeed avoids one round-trip to the AS to authenticate the user. It's just that it cannot be used with javascript SPAs or mobile applications.

Answer 2

Despite the additional round trip to the AS to exchange the code for an ID Token, the code flow has several security advantages over the Implicit or Hybrid Flow:

1. The client / RP can be authenticated, since it is an confidential client and thus can be equipped with client credentials (asymmetric keys in the case of Apple). This is a security improvement, since the client credentials are necessary to redeem the code.
2. The claims about the user can be obtained via UserInfo endpoint and don't need to be included in the ID Token, which has several advantages:
   • the ID Token can be much smaller
   • the ID Token is not necessarily exposed to the front channel (→ the end user’s browser)
   • in case the ID Token is provided in the id_token_hint parameter to request a specific user or in the RP-Initiated Logout, a smaller ID Token with less sensitive data is better
3. If Apple only supports the Hybrid Flow and not the Implicit Flow, they might not include all claims about the user in the ID Token, since the client has the ability to use the Access Token to request them from the UserInfo endpoint. IdentityServer uses this behaviour.