Not authorized error when selecting wrong account.

[codestation]

I am still seeing the #103 problem even after upgrading to 2.2.0 (thomseddon/traefik-forward-auth:v2.2.0). If i choose the email in the whitelist then it works properly and i am redirected to my original page, but if i choose the wrong email by mistake then i end with the "Not authorized" message and no way out until i delete the cookies.

My configuration is the following (using Auth Host Mode and Selective Authentication):

Environment:

version: '3.5'
services:
  forward-auth:
    image: thomseddon/traefik-forward-auth:v2.2.0
    environment:
      CONFIG: /run/secrets/credentials
      AUTH_HOST: auth.example.com
      WHITELIST: codestation@example.com
      COOKIE_DOMAIN: example.com
      LOG_LEVEL: debug
    secrets:
      - credentials
    networks:
      - gateway
    deploy:
      placement:
        constraints:
          - node.role == manager
      labels:
        - traefik.enable=true
        - traefik.http.routers.oauth.rule=Host(`auth.example.com`)
        - traefik.http.routers.oauth.entryPoints=https
        - traefik.http.routers.oauth.middlewares=oauth-verify
        - traefik.http.routers.oauth.tls=true
        - traefik.http.routers.oauth.tls.certresolver=dns
        - traefik.http.routers.oauth.tls.domains[0].main=example.com
        - traefik.http.routers.oauth.tls.domains[0].sans=*.example.com
        - traefik.http.services.oauth.loadbalancer.server.port=4181
        - traefik.http.middlewares.oauth-verify.forwardauth.address=http://forward-auth:4181
        - traefik.http.middlewares.oauth-verify.forwardauth.authResponseHeaders=X-Forwarded-User

secrets:
  credentials:
    name: oauth2_credentials
    file: ./credentials.ini

networks:
  gateway:
    external: true

Credential file contents

client-id = xxxxxxxxxxxx.apps.googleusercontent.com
client-secret = xxxxxxxxxxxxx
secret = xxxxxxxxxxxxxxxxxx

The protected service has the following label:

traefik.http.routers.myservice.middlewares=oauth-verify

I can see the following in the logs:

level=warning msg="Invalid email" email=wrongaccount@gmail.com handler=Auth host=myservice.example.com method=GET proto=https rule=default source_ip=xxx.xxx.xxx.xxx uri=/

The log is expected since i choose the wrong account, but IMO it should redirect to the auth page and never show the error message on the page (or show the error page with a button to login again).

[dantebarba]

+1. Should be an escape out from "Not Authorized".

[thomseddon]

I'll double check this again

[thomseddon]

Just tested this and confirmed this is still the behaviour - currently the auth cookie will still be generated for an invalid user which I believe is a bug.

I've added the user verification into a local branch, but I need to decide on the best way to handle it it, I'll do a bit more testing on options.

[thomseddon]

I'm still unsure on the best way to handle this, the two options I see:

1. Show the Not Authorized page - this will be prior to redirect, so refreshing the page will result in another Not Auhorized, the user would need to repeat the initial request to try again, but it shows them there has been an error
2. Don't set the cookie, redirect them to their original request - this will case them to be redirected back to the provider login. This would mean if they select an authorised user account, they would then be correctly redirected back to their originally requested location, but it also doesn't provide any feedback and the user would experience a "loop" behaviour

I think 1. is the better option, I welcome any other feedback on this

[dantebarba]

Number one is the best option to me. I don't know if it's already implemented, but a custom redirect URI for Not Authorized would be great. So we could design our own redirect schema. For example I would just load an HTML with a "Ops!, you are not authorized to view this page, click here to go back to login".

[JoshGlazebrook]

I'm also running into this. I'd be fine with either option, although I think in most cases services tend to just use option 2 and redirect back to the app which then redirects back to the identity provider.

[timekills]

For Google OAuth, if the "prompt" parameter were available as an option, it could be set to "select_account" which forces an account selection.
Presumably would defeat the cookie life if it were a mandatory account selection each time, but I believe this is only when the cookie ahs expired.
This way it doesn't automatically select the logged in account as the mandatory account, but forces the user to choose the account when they have to log in.

https://developers.google.com/identity/protocols/oauth2/web-server

[codestation]

Any update on this?

[luisvsm]

I've had a go at fixing it in #286 by clearing the auth cookie, specifically when the 401 Not authorized prompt is displayed because a user's email address is not valid.

I've also amending the message to prompt the user to refresh the page to try again.

It's a bit blunt and could definitely be done more elegantly but I'm not familiar with GO or this project's source code is it's about the best that I can manage and will hopefully enough until someone can come along with a more elegant solution.