0

It's seeming like the extra loop via the client backend in code flow only adds obscurity - not security. If, in the end, the client backend dishes out the same access token to the front end as the auth server would via implicit flow, what specific attack is mitigated by the extra back channel communication?

Having read around on the topic, it sounds like code flow's superiority is only achieved if the client front end never sees the access token. Is that true?

1

1st question: it mitigates attacks described in OAuth 2.0 Security Best Current practice draft-ietf-oauth-security-topics-133.1.2. Implicit Grant, mainly: - browser history token leakage - compromised devices where an attacker can somehow manipulate the client (such as a malicious browser extension)

2nd question: the client will necessarily have to use the acces token. In the authorization code flow, however, the access token doesn't go through the web flow which helps with mitigating attacks on the web stack. On the contrary, it exchanges the authorization code against tokens on the /token API direct. Moreover, use of PKCE prevents an attacker from using an authorization code intercepted in the browser or on the host application (eg. on mobiles, by claiming the redirect URI which cannot be owned by a single application).

  • Thanks for the link! But in a case where the client backend finally gives the code flow's access token in the URL fragment to the client front end, it's as insecure as implicit flow, right? I mean, why does it matter in the end whether the one returning the access token is the auth server or the client backend? So to achieve that infamous code-flow security, we'd have to make it so that the front end doesn't see the token, eg. by proxying all resource request via the client backend, and having the access token in a secure HttpOnly cookie. – user3397781 Jul 29 at 3:33
-1

I will try in simple words. Authorization Code flow should be used by applications where you have a backend (like ASP.NET MVC, Spring,). This flow uses intermediate code value which in the backed will be exchanged to access token. After that access token can be stored securely in application backed and used whenever is needed. In this use case, access token is never exposed to the browser (if application will not reveal it).

Implicit flow send back the access token directly in the authentication response. When used in browser app (applications without a backend) it is necessary to store it securely which is not that easy. In this case it is adviced to use PKCS instead and short-lived access tokens.

  • No, this is wrong. The latest advice from the OAuth2 mailing list is to not use implicit anymore, but instead authorization code even for javascript and native mobile applications. Also, you should define stored securely. A backend can be hacked, its logs can contain the access tokens if not configured properly, TLS might not be used between backend servers, etc. Finally, an SPA will have to store the access token on the browser side somehow, you can't avoid that. – Tangui Jul 27 at 15:05
  • Also, this point speaks more to why exposing/storing a token in the front end is less secure than in the backend, and less to the levels of security in the flows themselves, even if there is an obvious connection – user3397781 Jul 29 at 3:37
  • Why do you think this answer is wrong? This is adviced to not use implicit flow. As a secure storage I mean for example in-memory. From my practice, im my projects i am not using regresh tokens and instead Access tokens on form of JWT, I use reference tokens. – Bartosz Rosa Jul 30 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.