3 ms·

Just a quick one in case it's helpful to others: On the topic of redirect attacks, this works only if the oauth flow does not have a third leg. This is where th

by nstart 5y ago

Just a quick one in case it's helpful to others: On the topic of redirect attacks, this works only if the oauth flow does not have a third leg. This is where the the token granted at the end of the redirect must be sent to the server of the legitimate company. The token is combined with a secret to then retrieve a final access token with the actual permission to access the API on the user's behalf. That final token is retrieved entirely on the server side and is never sent to the user's device and in that way you are protected from an open redirect attack. Happy to be corrected on any of the above. My knowledge here is very much a WIP.

littlecranky67 5y ago
> That final token is retrieved entirely on the server side and is never sent to the user's device To my experience, this is often bypassed/changed for SPA+REST service architectures. The problem is with a SPA, I need to obtain some form of authentication token that I present to my backend services - so people expose the access token directly to the browser, which in turn uses it when communicating to the Backend services.
- jodersky 5y ago
  There's an OAuth 2.0 extension called PKCE (https://oauth.net/2/pkce/ https://oauth.net/2/pkce/) which mitigates this issue, and from what I understand it will be mandatory in OAuth 2.1. Essentially, the idea behind it is that the client (the web app in this case) dynamically registers itself with a secret at the authentication server. After receiving the code, it uses a hash derived from the secret to authenticate itself. An attacker who intercepts the authorization code, would not be able to exchange it for a token, since they don't have the secret. Section 1.1 of the RFC (https://datatracker.ietf.org/doc/html/rfc7636#section-1.1 https://datatracker.ietf.org/doc/html/rfc7636#section-1.1) has a very concise and clear explanation.
  - littlecranky67 5y ago
    Thanks for sharing, looks interesting. However it is an extension to the "code flow". My main point was that lots of people do not use the code flow but rather stick with the "implicit flow" which directly hands out access tokens to the browser. If you opt for the "code flow", you need some sort of auth backend in your stack, that proxies all calls to services (since the token is only available in the BE).
    - jodersky 5y ago
      Yes indeed, you are right that this is not part of the implicit flow mechanism. AFAIU, the recommendation from OAuth 2.1 is to drop the use of implicit flows in web apps and instead rely on code flows with PKCE. The idea would be that the web app registers itself as a so-called "public client" (see https://oauth.net/2/client-types/ https://oauth.net/2/client-types/) when it is loaded and then uses the standard code flow with PKCE.
      - mooreds 5y ago
        I wrote a doc about the differences between OAuth2 and (proposed) OAuth 2.1, which might be helpful: https://fusionauth.io/learn/expert-advice/oauth/differences-between-oauth-2-oauth-2-1 https://fusionauth.io/learn/expert-advice/oauth/differences-... It was based on this section with expanded examples: https://tools.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-differences-from-oauth-20 https://tools.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name... The implicit flow is bad for exactly the reasons mentioned: it exposes the access token (which is typically a bearer token) to the wild west environment of the browser. There are safe ways to have a token in a browser (as a secure, HTTPonly cookie, for example) but delivering the token in such a way as to allow any JS running on the page to have access to it is not one of them. Having a server side component which holds the client secret and can safely do the exchange buys you security, but it also buys you architectural flexibility. You can decide where the token should live (on the client, sent down as a cookie or to be stored in memory or on the server, using the BFF pattern and sessions to tie the client to this token).
        littlecranky67 5y ago

by nstart 5y ago

littlecranky67 5y ago

> That final token is retrieved entirely on the server side and is never sent to the user's device To my experience, this is often bypassed/changed for SPA+REST service architectures. The problem is with a SPA, I need to obtain some form of authentication token that I present to my backend services - so people expose the access token directly to the browser, which in turn uses it when communicating to the Backend services.

jodersky 5y ago
There's an OAuth 2.0 extension called PKCE (https://oauth.net/2/pkce/ https://oauth.net/2/pkce/) which mitigates this issue, and from what I understand it will be mandatory in OAuth 2.1. Essentially, the idea behind it is that the client (the web app in this case) dynamically registers itself with a secret at the authentication server. After receiving the code, it uses a hash derived from the secret to authenticate itself. An attacker who intercepts the authorization code, would not be able to exchange it for a token, since they don't have the secret. Section 1.1 of the RFC (https://datatracker.ietf.org/doc/html/rfc7636#section-1.1 https://datatracker.ietf.org/doc/html/rfc7636#section-1.1) has a very concise and clear explanation.
- littlecranky67 5y ago
  Thanks for sharing, looks interesting. However it is an extension to the "code flow". My main point was that lots of people do not use the code flow but rather stick with the "implicit flow" which directly hands out access tokens to the browser. If you opt for the "code flow", you need some sort of auth backend in your stack, that proxies all calls to services (since the token is only available in the BE).
  - jodersky 5y ago
    Yes indeed, you are right that this is not part of the implicit flow mechanism. AFAIU, the recommendation from OAuth 2.1 is to drop the use of implicit flows in web apps and instead rely on code flows with PKCE. The idea would be that the web app registers itself as a so-called "public client" (see https://oauth.net/2/client-types/ https://oauth.net/2/client-types/) when it is loaded and then uses the standard code flow with PKCE.
    - mooreds 5y ago
      I wrote a doc about the differences between OAuth2 and (proposed) OAuth 2.1, which might be helpful: https://fusionauth.io/learn/expert-advice/oauth/differences-between-oauth-2-oauth-2-1 https://fusionauth.io/learn/expert-advice/oauth/differences-... It was based on this section with expanded examples: https://tools.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-differences-from-oauth-20 https://tools.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name... The implicit flow is bad for exactly the reasons mentioned: it exposes the access token (which is typically a bearer token) to the wild west environment of the browser. There are safe ways to have a token in a browser (as a secure, HTTPonly cookie, for example) but delivering the token in such a way as to allow any JS running on the page to have access to it is not one of them. Having a server side component which holds the client secret and can safely do the exchange buys you security, but it also buys you architectural flexibility. You can decide where the token should live (on the client, sent down as a cookie or to be stored in memory or on the server, using the BFF pattern and sessions to tie the client to this token).
      - littlecranky67 5y ago